4

I'm repeatedly getting 403 Permission Denied errors on trying to serve images from apache running on Machine A. The images are in a directory which is an NFS share from Machine B. The entry on Machine B /etc/exports reads like this : /dir/ xxx.xxx.xxx.xxx(rw,sync,no_root_squash)

I'm able to browse the NFS mounted files/directories on Machine A successfully.

After going through httpd.conf, I also uncommented the options EnableMMAP off and EnableSendFile Off as written there.

Both machines are on RHEL5.

Improve this question

4 Answers 4

Reset to default
7

Finally resolved this. It had been an SELinux issue all along. Found the solution here - http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/rhlcommon-section-0068.html

In Red Hat Enterprise Linux 4 most targeted daemons do not interact with user data and are not affected by NFS-mounted home directories. One exception is Apache HTTP. For example, CGI scripts that are on the mounted file system have the nfs_t type, which is not a type httpd_t is allowed to execute.

Setting SELinux to permissive on the relevant servers did the job for me.

Improve this answer
6
  • Thanks for tracking this down, I knew I should have just disabled SELinux when I setup the system X-(
    – Dana the Sane
    Mar 9, 2011 at 14:58
  • You're most welcome :). I know how you feel, took me ages to figure this out!
    – s1d
    Aug 3, 2011 at 17:20
  • THANKS SO MUCH ... i had no clue what was happening ... saved me hours
    – sbditto85
    Dec 28, 2011 at 18:42
  • 4
    You can also use setsebool -P httpd_use_nfs 1 to allow apache to access NFS shares.
    – Terence Johnson
    Aug 23, 2013 at 16:22
  • Broken URL, I think it's this now --> access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…
    – djhaskin987
    Sep 8, 2014 at 19:26
1

NFS always causes fun things to happen like this whenever UID/GIDs aren't lined up just right.

Assuming that your webserver is running as user "apache", make sure that the permissions on the file are such that they're world-readable.

su to the apache user and cd to the directory, and try cat'ing the files.

It's most likely a permission issue. If apache isn't writing to the directory, it doesn't care if the files it's reading are on NFS or anything else.

Improve this answer
4
  • Hmm. ls -n on the respective directory in Machine A (apache) shows this : drwxr-xr-x 4 0 0 4096 Jun 1 15:53 dirname ls -n output on Machine B (nfs source) : drwxr-xr-x 4 0 0 4096 Jun 1 15:53 dirname Both have root as user/group. Even changing a file's permissions to 777 does not help. The files are all images so only a read should be enough. But I still get the 403 error nonetheless.
    – s1d
    Jun 3, 2009 at 10:11
  • I wonder why the formatting got screwed above. Btw, did try su - apache but I get the following message : This account is currently not available.
    – s1d
    Jun 3, 2009 at 10:15
  • 1
    The user apache isn't usually given a shell for security purposes. If you wish to test, you can use the command su - apache -s /bin/bash, which will override the shell set in /etc/passwd.
    – Dan Carley
    Jun 3, 2009 at 10:28
  • I created a test text file on Machine B. It shows up alright when I su - apache on Machine A using your method and cat it.
    – s1d
    Jun 3, 2009 at 10:54
0

In addition to Matt's suggestion, also check that Apache is permitted to serve files from where your NFS mount point exists. For security purposes a lot Apache distributions come with a restrictive directive like so:

<Directory />
    Options FollowSymLinks
    AllowOverride None
    Order deny,allow
    Deny from all
</Directory>

This prevents any files being served from / and above. Typically you will then have a less restrictive rule to allow another directory, which contains your DocumentRoots, to serve up files a little more freely.

I'm unfamiliar with how RHEL5 distributes it's Apache config files. But you may need to create an additional Directory directive to permit files being served from your mount point.

Improve this answer
3
  • Currently the setting for the directory set as DocumentRoot is AllowOverride All. The NFS share is mounted inside that directory itself.
    – s1d
    Jun 3, 2009 at 10:30
  • Can you access files over HTTP from the parent directory, below the mount point? Also at a slight tangent is there a sec= option on the mount when you cat /proc/mounts from Machine A. If so, what does it say?
    – Dan Carley
    Jun 3, 2009 at 11:01
  • I assume you said if I can access /dir/image.jpg where /dir/nfs is the NFS mount, yes I can. I didn't see any sec= option in /proc/mounts on Machine A (apache). I'm pasting the relevant line here for your reference : nfsd /proc/fs/nfsd nfsd rw 0 0 xxx.x.x.x:/dir/images /var/www/html/dir/images nfs rw,vers=3,rsize=32768,wsize=32768,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=xxx.x.x.x 0 0
    – s1d
    Jun 3, 2009 at 11:16
-1

I had this exact problem.

I am on Xubuntu and the www-data user (apache) did not have access to an nfs mount.

before 'sudo mount -a' the mount point was...

drwxrwxrwx

but after

drwxrwx---

somebody mentionned changing the group of the dir to www-data, but i just chmodded it back to 777 after the mount. I need to read up on nfs mounts to do that automatically

Improve this answer
3
  • 2
    I'm not sure chmod 777 is the best advice.
    – Drew Khoury
    Feb 5, 2014 at 19:15
  • 1
    I'm pretty sure 777 is absolutely the wrong advice... sure it'll work, but there are precious few situations that removing all restrictions to a file are actually a good idea.
    – Hunter Eidson
    Feb 5, 2014 at 19:34
  • Bad Idea. I always avoid using chmod 777.
    – s1d
    Feb 6, 2014 at 5:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .