By Angus Ireland


2011-07-22 19:53:51 8 Comments

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?

11 comments

@David Ding 2019-04-08 06:16:27

If you're using SELinux, just type:

sudo chcon -v -R --type=httpd_sys_content_t /path/to/www/

This will fix permission issue.

@Harshal 2019-03-04 10:30:52

I was facing the same issue but above solutions did not help.

So, after lot of struggle I found out that sestatus was set to enforce which blocks all the ports and by setting it to permissive all the issues were resolved.

sudo setenforce 0

Hope this helps someone like me.

@Angus Ireland 2019-03-06 17:07:49

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

@Anderson 2014-12-16 07:11:53

I solved this problem by adding user settings.

in nginx.conf

worker_processes 4;
user username;

change the 'username' with linux user name.

@CamelBlues 2015-01-08 20:40:48

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 2015-01-16 00:15:36

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.

@Gabriel A. Zorrilla 2015-04-19 21:05:19

Had to add usergroup as well: user usegroup.

@kvdv 2015-07-08 19:12:20

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.

@Robins Gupta 2016-03-14 19:50:34

@Anderson Thanks worked for me.

@psychok7 2016-09-10 14:20:29

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?

@thangdc94 2017-05-11 15:17:01

This should be marked as accepted answer. Thank you

@Francisco Zanatta 2018-06-11 20:39:59

If you are using PHP, make sure the index NGINX directive in the server block contains a index.php:

index index.php index.html;

For more info checkout the index directive in the official documentation.

@Slavomir Miskovec 2017-03-22 23:29:53

We had the same issue, using Plesk Onyx 17. Instead of messing up with rights etc., solution was to add nginx user into psacln group, in which all the other domain owners (users) were:

usermod -aG psacln nginx

Now nginx has rights to access .htaccess or any other file necessary to properly show the content.

On the other hand, also make sure that Apache is in psaserv group, to serve static content:

usermod -aG psaserv apache

And don't forget to restart both Apache and Nginx in Plesk after! (and reload pages with Ctrl-F5)

@David 2016-04-30 02:13:54

Old question, but I had the same issue. I tried every answer above, nothing worked. What fixed it for me though was removing the domain, and adding it again. I'm using Plesk, and I installed Nginx AFTER the domain was already there.

Did a local backup to /var/www/backups first though. So I could easily copy back the files.

Strange problem....

@jsina 2016-04-03 17:56:11

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.

@Pankaj Garg 2017-10-12 04:32:02

Thanks @jsina, this helped me a lot

@jww 2019-03-26 17:20:40

Damn, +1, me too.

@danvk 2014-11-05 17:24:42

I dug myself into a slight variant on this problem by mistakenly running the setfacl command. I ran:

sudo setfacl -m user:nginx:r /home/foo/bar

I abandoned this route in favor of adding nginx to the foo group, but that custom ACL was foiling nginx's attempts to access the file. I cleared it by running:

sudo setfacl -b /home/foo/bar

And then nginx was able to access the files.

@Kurt 2014-10-07 03:40:51

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

@ub3rst4r 2014-10-29 05:51:43

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 2014-11-03 19:54:26

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 2014-11-14 15:27:24

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

@timss 2015-02-14 23:19:55

This is default behavior on CentOS 7 aswell.

@eddy147 2015-09-25 20:19:39

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 2015-11-23 03:25:49

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 2016-04-14 13:16:15

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 2016-06-21 15:44:53

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.

@Florin Andrei 2017-01-08 07:23:29

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 2017-04-12 22:53:00

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.

@NotHereAnymore 2017-06-03 17:03:17

You've just saved my life @Kurt

@silverdr 2017-11-29 11:24:35

That's a lifesaver. Thanks, Man!

@Ted Corleone 2018-04-20 04:15:54

Saved my life + 1!!! @Kurt

@Runny Yolk 2018-05-29 06:04:37

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

@Ebrahim Karimi 2019-02-02 11:25:28

you saved my day:)

@Khom Nazid 2019-06-29 17:28:38

This is the correct answer.

@Andron 2013-03-20 16:50:04

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.

@kvdv 2015-07-08 19:08:23

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.

@Andron 2015-07-10 10:05:07

Mr. Anderson? No! Andron ;)

@kvdv 2015-07-14 12:40:44

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

@Andron 2015-07-15 12:14:18

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

@gontard 2016-12-02 10:52:59

Isn't this a security issue ?

@kolbyjack 2011-07-22 22:11:38

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

@jjt 2012-04-13 18:49:56

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

@Peter Ehrlich 2012-12-29 02:48:56

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

@JoshuaDavid 2014-05-23 06:03:22

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

@kolbyjack 2014-05-23 12:46:27

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 2014-07-10 20:49:07

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)

@le_me 2014-07-28 11:55:15

awesome!!! helped me a lot!

@Ian Lewis 2014-12-22 22:07:01

This tip has been useful twice so far. Thanks!

@Manatax 2015-08-04 05:31:07

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

@backdesk 2017-05-10 15:26:53

I REALLY wish I had read this 4 hours ago. Thank you.

@kashiraja 2019-02-21 07:19:33

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!

Related Questions

Sponsored Content

15 Answered Questions

3 Answered Questions

nginx change root folder for specyfic url

  • 2013-06-27 07:24:06
  • kabra
  • 13008 View
  • 6 Score
  • 3 Answer
  • Tags:   nginx path root

11 Answered Questions

[SOLVED] Node.js + Nginx - What now?

  • 2011-02-15 20:49:02
  • Van Coding
  • 331703 View
  • 941 Score
  • 11 Answer
  • Tags:   node.js nginx concept

3 Answered Questions

[SOLVED] Share Nginx server configuration

  • 2014-06-11 04:04:32
  • Anam
  • 1557 View
  • 4 Score
  • 3 Answer
  • Tags:   php nginx

0 Answered Questions

Cannot get index.php page to display in docker container

  • 2019-02-06 04:42:32
  • sp156
  • 173 View
  • 0 Score
  • 0 Answer
  • Tags:   php docker nginx

2 Answered Questions

[SOLVED] can't interpret PHP on RHEL + nginx

  • 2017-06-08 17:33:56
  • Night
  • 107 View
  • 1 Score
  • 2 Answer
  • Tags:   php linux nginx

3 Answered Questions

[SOLVED] NGINX try_files + alias directives

  • 2013-12-06 14:49:33
  • Alex Kovytin
  • 21595 View
  • 30 Score
  • 3 Answer
  • Tags:   nginx

1 Answered Questions

Nginx 1.6.2 / PHP, limit website php to /

  • 2017-05-10 15:25:13
  • François Pignon
  • 97 View
  • 1 Score
  • 1 Answer
  • Tags:   php nginx

0 Answered Questions

1 Answered Questions

[SOLVED] migrating from lighttpd to nginx

Sponsored Content