I am trying to set up my own web server to learn a bit more about server admin.

I have decided that I want to serve each sites files from a public_html folder inside the users /home directory.

I have installed Nginx, edited the nginx.conf and changed the username / group to nginx.

I have added a new user for the new site and changed the vhosts file to look like so;

server {
    listen         80;
    listen         [::]:80;
    server_name    website.com www.website.com;
    root           /home/website/public_html;
    index          index.html index.htm index.php;

    location / {
      try_files $uri $uri/ =404;

    location ~* \.php$ {
    fastcgi_pass unix:/var/run/php-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;

But when I try and get to the site, it returns a 404 Not Found.

When I check the error log, I am seeing the following errors;

2019/01/02 19:49:45 [crit] 18248#0: *1 stat() "/home/website/public_html/" failed (13: Permission denied)

Any chance someone has come across this before and could tell me how to handle it?

I have had a look around and saw some posts about getenforce, but when i run it, it says Disabled.

I am using CentOS7 if that makes any difference.


  • 1
  • @JennyD .. Im using nginx not Apache
    – Chris
    Jan 2, 2019 at 10:45
  • 1
    You need the same basic set of permissions regardless of which webserver you're running. Obviously you need to replace the username apache with whatever username nginx is running under.
    – Jenny D
    Jan 2, 2019 at 11:10
  • No, that didn't work ... Im still getting the exact same errors
    – Chris
    Jan 2, 2019 at 11:22
  • Don't serve web sites from user home directories, for a wide variety of reasons. Jan 2, 2019 at 14:04

7 Answers 7


Following the guide from this website did it for me (as root):

setsebool -P httpd_enable_homedirs 1
systemctl daemon-reload
systemctl restart nginx

A good way to debug such nginx errors is by checking the logs and using namei to check whether nginx has access to all ancestor folders.

Consider /static/vendor.js gives a HTTP 403 due to this configuration:

server {
    listen 80;

    location /static/ {
    alias /home/ubuntu/bla/front/dist/;

First check out nginx access logs, in ubuntu it's here:

tail /var/log/nginx/error.log

Mine says:

2023/07/25 11:52:05 [error] 15138#15138: *3 open() "/home/ubuntu/bla/front/dist/vendor.js" failed (13: Permission denied), client:, server: , request: "GET /static/vendor.js HTTP/1.1", host: "

I notice the file /home/ubuntu/bla/front/dist/vendor.js does exist, so I check whether www-data (nginx user) can access it:

sudo -u www-data namei /home/ubuntu/bla/front/dist/vendor.js

f: /home/ubuntu/bla/front/dist/vendor.js
 d /
 d home
 d ubuntu
   bla - Permission denied

Apparently the bla folder can't be accessed, this is likely due to not having rx rights on the ubuntu folder. That is, if the parent can't be read, the child is invisible. I'll fix this using setfacl, a way to give fine-grained ACL permissions without changing the user and group of a file.

sudo setfacl -m g:www-data:rx /home/ubuntu/

And now:

sudo -u www-data namei /home/ubuntu/bla/front/dist/vendor.js

f: /home/ubuntu/bla/front/dist/vendor.js
 d /
 d home
 d ubuntu
 d bla
 d front
 d dist
 - vendor.js

The file is accessible by www-data, and also nginx's 403 disappeared.

  • 2
    You deserve some kind of prize for being the only person I found on the whole internet who intelligently suggested using namei to test the permissions on a certain file using a certain user, which shows exactly where the issue is. THANK YOU kind stranger.
    – DelPiero
    Dec 13, 2023 at 20:47
  • @DelPiero Glad to hear it helped you. It's not entirely altruistic though. As a data scientist (or whatever I'm called these days) certain Linux and nginx knowledge tends to get lost, and I'll be happy to read my own answer as a refresher.
    – Herbert
    Dec 30, 2023 at 15:37
  • 1
    I've come here to echo what @DelPiero said. @Herbert, you deserve a special kind of praise. Nowhere else has anyone mentioned or hinted to use namei to see exactly where the permission is failing in the "directory tree". I used the command to fine tune permissions for the directories. Thank you so much. It's not only a solution to this nginx problem but it's an extremely valuable command for troubleshooting permissions anywhere on a linux box.
    – lukik
    Apr 17 at 3:32
  • @lukik I don't know what to say, thank you for your kind words and good luck in the linuxsphere!
    – Herbert
    Apr 17 at 10:35

Better fix: ls -Z myFile.js will show the SELinux context: -rw-r--r--. nginx nginx unconfined_u:object_r:user_home_t:s0 myFile.js Then, use chcon -v --type=httpd_sys_content_t myFile to change the SELinux content. I did it with Andrew Richard Miller's answer. https://stackoverflow.com/questions/25774999/nginx-stat-failed-13-permission-denied#comment84000833_30897591


It is your home directory permission that is denying access to nginx.


ls -ld /home/website


setfacl -R -m u:nginx:rwx /home/website


chown -R nginx:nginx /home/website
chmod 655 /home/website
  • 1
    default user for nginx is www-data so it's likely going to need to be sudo chown -R www-data:www-data /home/website Jan 2, 2019 at 12:13
  • @samayres1992 user created for centos/rhel is 'nginx'
    – JKhan
    Jan 12, 2019 at 8:16
  • @TedKhi Samayres is right though. Unless you also explain that you need to change the default user that nginx runs as by updating /etc/nginx/nginx.conf to change the user www-data line to read user nginx instead, then the above would not work (unless they had already done that).
    – James
    Jan 13, 2020 at 14:49
  • worked for me. I had to do 777 instead of 655. Thanks
    – Renil Babu
    Apr 14, 2020 at 13:36
  • 3
    @RenilBabu Using 777 is a bad idea - that means ANYONE can write to you directory. Use 755 instead
    – TetraDev
    Oct 25, 2020 at 20:47

The solution for me was to set the /home/user/public_html permissions to 755. By default, it was being created with 751 permissions. This was blocking the nginx user from being able to 'read' it. Certain web hosting panels like VestaCP, CPanel, and others may inadvertently do this when adding a new site through their interface.

Solution: sudo chmod 755 ~/public_html (adjust path to your public_html folder)


In my case, it was fixed (from this blog) by running the command: semanage permissive -a httpd_t and restarting NGINX service.

  • 1
    After several tries, this worked for me.
    – Lingam
    Jun 17, 2023 at 16:19

The {13: permission denied} error most likely due to the SElinux policy rules. check sudo sestatus if it SELinux status:enabled then you need to find out which context is blocked by SElinux. most likely it is httpd_t you can identify this by running ps axZ | grep httpd this command. It shows which context label is given to the nginx process. and to add it in permissive, execute this command sudo semanage permissive -a httpd_t. then restart nginx and app server.

You must log in to answer this question.

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