7

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.

Cheers,

Chris
  • 73
  • 1
  • 1
  • 4
  • 1
    Possible duplicate of [What permissions should my website files/folders have on a Linux webserver?](https://serverfault.com/questions/357108/what-permissions-should-my-website-files-folders-have-on-a-linux-webserver) – Jenny D Jan 02 '19 at 10:43
  • @JennyD .. Im using nginx not Apache – Chris Jan 02 '19 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 02 '19 at 11:10
  • No, that didn't work ... Im still getting the exact same errors – Chris Jan 02 '19 at 11:22
  • Don't serve web sites from user home directories, for a wide variety of reasons. – Michael Hampton Jan 02 '19 at 14:04
  • Is `selinux` enabled? – chicks Jan 03 '19 at 03:30

7 Answers7

9

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

setsebool -P httpd_enable_homedirs 1
setenforce 0
systemctl restart nginx
systemctl daemon-reload
edrichhans
  • 91
  • 1
  • 3
1

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)

TetraDev
  • 111
  • 2
1

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

thach.nv92
  • 31
  • 3
1

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

Genarito
  • 111
  • 1
1

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

Try:

ls -ld /home/website

then

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

Or

chown -R nginx:nginx /home/website
chmod 655 /home/website
JKhan
  • 127
  • 7
  • 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``` – samayres1992 Jan 02 '19 at 12:13
  • @samayres1992 user created for centos/rhel is 'nginx' – JKhan Jan 12 '19 at 08: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 '20 at 14:49
  • worked for me. I had to do 777 instead of 655. Thanks – Renil Babu Apr 14 '20 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 '20 at 20:47
0

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: 145.90.169.214, server: , request: "GET /static/vendor.js HTTP/1.1", host: "129.125.55.156

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.

Herbert
  • 121
  • 1
  • 1
  • 5
0

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.