Nginx 403 forbidden for all files

Question

I have nginx installed with PHP-FPM on a CentOS 5 box, but am struggling to get it to serve any of my files - whether PHP or not.

Nginx is running as www-data:www-data, and the default "Welcome to nginx on EPEL" site (owned by root:root with 644 permissions) loads fine.

The nginx configuration file has an include directive for /etc/nginx/sites-enabled/*.conf, and I have a configuration file example.com.conf, thus:

server {
 listen 80;

 Virtual Host Name
 server_name www.example.com example.com;


 location / {
   root /home/demo/sites/example.com/public_html;
   index index.php index.htm index.html;
 }

 location ~ \.php$ {
  fastcgi_pass   127.0.0.1:9000;
  fastcgi_index  index.php;
  fastcgi_param  PATH_INFO $fastcgi_script_name;
  fastcgi_param  SCRIPT_FILENAME  /home/demo/sites/example.com/public_html$fastcgi_script_name;
  include        fastcgi_params;
 }
}

Despite public_html being owned by www-data:www-data with 2777 file permissions, this site fails to serve any content -

 [error] 4167#0: *4 open() "/home/demo/sites/example.com/public_html/index.html" failed (13: Permission denied), client: XX.XXX.XXX.XX, server: www.example.com, request: "GET /index.html HTTP/1.1", host: "www.example.com"

I've found numerous other posts with users getting 403s from nginx, but most that I have seen involve either more complex setups with Ruby/Passenger (which in the past I've actually succeeded with) or are only receiving errors when the upstream PHP-FPM is involved, so they seem to be of little help.

Have I done something silly here?

Solution 1

One permission requirement that is often overlooked is a user needs x permissions in every parent directory of a file to access that file. Check the permissions on /, /home, /home/demo, etc. for www-data x access. My guess is that /home is probably 770 and www-data can't chdir through it to get to any subdir. If it is, try chmod o+x /home (or whatever dir is denying the request).

EDIT: To easily display all the permissions on a path, you can use namei -om /path/to/check

Solution 2

If you still see permission denied after verifying the permissions of the parent folders, it may be SELinux restricting access.

To check if SELinux is running:

# getenforce

To disable SELinux until next reboot:

# setenforce Permissive

Restart Nginx and see if the problem persists. To allow nginx to serve your www directory (make sure you turn SELinux back on before testing this. i.e, setenforce Enforcing)

# chcon -Rt httpd_sys_content_t /path/to/www

See my answer here for more details

Solution 3

I solved this problem by adding user settings.

in nginx.conf

worker_processes 4;
user username;

change the 'username' with linux user name.

Solution 4

I've got this error and I finally solved it with the command below.

restorecon -r /var/www/html

The issue is caused when you mv something from one place to another. It preserves the selinux context of the original when you move it, so if you untar something in /home or /tmp it gets given an selinux context that matches its location. Now you mv that to /var/www/html and it takes the context saying it belongs in /tmp or /home with it and httpd is not allowed by policy to access those files.

If you cp the files instead of mv them, the selinux context gets assigned according to the location you're copying to, not where it's coming from. Running restorecon puts the context back to its default and fixes it too.

Solution 5

I've tried different cases and only when owner was set to nginx (chown -R nginx:nginx "/var/www/myfolder") - it started to work as expected.

View more solutions

Comments

[sandes]

check this answer stackoverflow.com/questions/16808813/…

[jjt]

Same here. On my install of CentOS 6, /home/user dirs are set to 700 by default.

[Peter Ehrlich]

This guy talks about it too: (chmod -4 +x /mypath worked for me) nginxlibrary.com/403-forbidden-error

[JoshuaDavid]

Can someone explain why this behavior is different than apache which does NOT require every parent directory to have "x" permissions?!?

[kolbyjack]

It isn't any different. The only reason apache wouldn't also require x permission on parent directories is if it's running as root.

[basicdays]

I ended up adding the www-data user to my personal user group and doing a chmod 710 to my root user folder. Worked like a charm. (On a debian based distro)

[SameOldNick]

I couldn't figure out why whenever I started nginx it said open() "/usr/share/nginx/logs/xxxxxx.com-error_log" failed (13: Permission denied) after I checked the permissions and made sure it was being started as root. I came across this and found out SELinux was enabled. I disabled it and now it works no problem. Thanks!

[Winter]

Thanks! I still had an issue with permission denied for users owning their own FPM sockets so I was able to fix that one by changing the user from nginx to root in /var/nginx/nginx.conf - perhaps that will help someone else who comes across this issue. S/O to DataPsyche for the second part.

[ILker Özcan]

i think centos 6.6 has a bug. Selinux breaks nginx.

[Ian Lewis]

This tip has been useful twice so far. Thanks!

[CamelBlues]

I believe this answer is better security wise than the accepted answer. You don't have to go messing around with the permissions on your home folder (which could contain sensitive information) and if you're doing development with nginx, it saves you from having to upload weird file permissions to SCM.

[Angus Ireland]

The added permissions on the home directory are execute, not read, thus no sensitive information is (in theory) revealed (except, in this case, perhaps to a malicious PHP script which recurses upwards and knows the location of the sensitive files within another directory accessible to www-data). You'll also notice that in the original question, my nginx was running as "www-data" - the configuration values here were already set as desired.

[timss]

This is default behavior on CentOS 7 aswell.

[Gabriel]

Had to add usergroup as well: user usegroup.

[kvdv]

Worked for me as well. I suspect this happens because even though nginx is started as root, it spawns processes under the user that is specified in the nginx.conf file, which is "user nginx;" by default. Changing the user to the user who owns your document root should also work as Anderson suggested.

[kvdv]

Worked for me as well (just as chmodding the dir to nginx:nginx). I prefer this solution though so I can have my document root owned by another user than nginx. Thanks Anderson for pointing this out.

[Andron]

Mr. Anderson? No! Andron ;)

[kvdv]

Apologies Mr. Andron ;) I can't seem to edit the previous comment anymore though...

[Andron]

Sure, not a problem. Now I was as Anderson :) and need to write some fairy tales...

[Manatax]

both the permission requirement and the namei tip helped me solve my issue.

[user3075901]

Thank you thank you. 95% Of the info on this are about permissions, but when they are all set 775, I really was pulling my hear out (all 6 of them).

[DOfficial]

Im with everybody else that commented. I was ready to throw my computer out the window. Nginx was configured properly, permissions where properly set, I even went as far to make everything 777 and still got permissions denied error.

[Kapitein Witbaard]

The better SELinux command for this is: semanage fcontext -a -t httpd_sys_rw_content_t "/path/to/www(/.)?"* and restorecon -v /path/to/www this will automatically give all your files in this path the correct SELinux rights. Also when new files are added. Use httpd_sys_content_t if you only need reading rights.

[TimStaley]

On Centos 7 (SELinux enabled), the simplest fix for me was setsebool httpd_read_user_content on (For static files hosted from a home directory, chmod'ed to world-readable) - Though I guess @KapiteinWitbaard's method above is more secure.

[psychok7]

saved my day. by the way what if the machine has multiple users and each user has his own website, how do i deal with it?

[gontard]

Isn't this a security issue ?

[Florin Andrei]

Thank you, i was looking all night for your solution, even set chown to nginx and 777 to all files in the directory but no success! You are great!

[Dexter]

Seems that there's no way this works in RHEL 6.x (and probably centos 6). There needs some additional steps in configuring selinux and perhaps even modifying things about Red Hat itself. Give up on any attempt to try to get it working on RHEL 6, I've been looking all over.

[JonathanBristow]

You've just saved my life @Kurt

[Pankaj Garg]

Thanks @jsina, this helped me a lot

[silverdr]

That's a lifesaver. Thanks, Man!

[Runny Yolk]

Kurt, you saved my bacon. I've spent many hours trying to fix a 403 error, and this was the solution.

[Ebrahim Karimi]

you saved my day:)

[kashiraja]

I had to add +x to a parent folder of www/ even though all the sub-folders of www/ had the x-bit set. Wow, this took a while to figure out!

[Angus Ireland]

While that might have fixed your problem - congrats! - that's a bit sad :-( See stopdisablingselinux.com - could you find a different workaround?

[jww]

Damn, ＋1, me too.

[tonysepia]

I would like to stress this point: the user needs permissions in EVERY PARENT DIRECTORY!

[Yossarian42]

autoindex on might help

[Dario Zadro]

This is the correct answer and it's most likely usermod -aG username www-data on most setups.

[ali Falahati]

I have the right permissions for folder /var/www/html but I get a permission error. my question is after installing nginx we have a user and group nginx. we should use this user for folder owner?

[smilingky]

I believe this is the best solution

[Josh Usre]

This was my problem as well.

[user167043]

saved my day!this should be the best answer of the question.

[Dwigt]

It would be helpful to add an explanation as to what this command does.