nginx stat 13: Permission denied error

[hwname]

Greetings,

I'm very happy with Vesta CP, thank you for this great software. I have had one small issue for a while with my CentOS 7 install and I think some others see it as well:

https://www.google.de/#q=vesta+stat+13+ ... estacp.com

What happens is that when a visitor requests a web resource, it is served. However, at the same time, it is written into error.log like so:

Code: Select all

2016/02/23 12:43:01 [crit] 1681#0: *42749 stat() "/home/adminusername/web/mysite.com/public_html/image.png" failed (13: Permission denied), client: xxx.xxx.xxx.xxx, server: mysite.com, request: "GET /image.png HTTP/1.1", host: "www.mysite.com"

If I go to http://www.mysite.com/image.png in a browser, the resource is found, and also the resource is written into the error.log. That means that my site works, but I can't really use my mysite.com.error.log for troubleshooting real errors because it is 50% of the size of my mysite.com.log (the access.log for my domain). It is also probably indicative of something not working as efficiently as it could. I am guessing it is related to nginx and that when it doesn't work, the request is passed on to apache so the site does remain functional. Maybe this is incorrect but it is my best guess for now.

Having checked out the accounts on the machine, I have the impression that the nginx account is called nginx. When I try to manually stat a web resource using the nginx account from the command line, I get the permission error:

Code: Select all

sudo -u nginx stat /home/adminusername/web/mysite.com/public_html/image.png
stat: cannot stat `/home/adminusername/web/mysite.com/public_html/image.png': Permission denied

This makes sense since it is making the reference from the path including the admin username and nginx is not in the usernames group, and maybe it has other permissions issues as well.

I wondered if this was an SELinux issue, but when I 'cat /etc/sysconfig/selinux' it shows that SELINUX=disabled, so I don't think that's the issue.

I was wondering if I could get some help troubleshooting this from the project, with some safe suggestions (i.e. not making significant permission changes to the web folders that reduce general security) for first figuring out what is happening here, and then correcting it.

Thank you for your assistance!

[hwname]

Having read this, I wondered if it was the same issue of a directory without execute capability:

http://serverfault.com/questions/170192 ... 263#170263

The only folder in the problematic path that wasn't already set to execute was public_html, and when I added +x to world just on this directory the errors stopped. My question is, is this safe? The permissions on public_html used to be 750 and now they are 751, otherwise no other changes were needed and the change was not made recursively.

[Felix]

I was facing the exact same issue! I had checked (and corrected) that all directories in the path had execute permissions, but the problem remained.

In my case, I had to add +read permission to others group for all folders inside public_html. So the mask is 0755 for all directories.

In case someone else is reading this and needs to do the same, I used the following command while I was inside /home/[user]/web/[domain]/public_html

Code: Select all

find . -type d -exec chmod 0755 {} \;