Apache throwing 403 on serving images from an NFS share

Question

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.

Solution 1

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.

Solution 2

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.

Comments

[s1d]

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]

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.

[Dan Carley]

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.

[s1d]

Currently the setting for the directory set as DocumentRoot is AllowOverride All. The NFS share is mounted inside that directory itself.

[s1d]

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.

[Dan Carley]

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?

[s1d]

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,r‌​etrans=2,sec=sys,add‌​r=xxx.x.x.x 0 0

[Dana the Sane]

Thanks for tracking this down, I knew I should have just disabled SELinux when I setup the system X-(

[s1d]

You're most welcome :). I know how you feel, took me ages to figure this out!

[sbditto85]

THANKS SO MUCH ... i had no clue what was happening ... saved me hours

[Terence Johnson]

You can also use setsebool -P httpd_use_nfs 1 to allow apache to access NFS shares.

[Drew Khoury]

I'm not sure chmod 777 is the best advice.

[Hunter Eidson]

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.

[s1d]

Bad Idea. I always avoid using chmod 777.

[djhaskin987]

Broken URL, I think it's this now --> access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Lin‌​ux/…

[dan]

@TerenceJohnson This a very old question (and answer) but you should post your comment as an actual answer and it should be the accepted answer. Disabling SELinux completely isn't a solution; configuring it properly is.