Issue nginx server logs filling with "openat()" errors

[G J Piper]

Ok I just finished updating two web servers from Plesk 12.5 to Onyx, and for some reason I'm getting a log entry for every static file, every time it is hit, in the nginx server logs like this:

[crit] 14490#0: *214 openat() "/any/static/file/path/file.ext" failed (13: Permission denied)

The websites all seem to load completely fine and everything on the outside seems to be quick and responsive, but these logs are filling up fast.

Anyone know of a solution?

 

[G J Piper]

Update:
Them errors only occur if this setting is turned ON:

 

[Bitpalast]

The symbolic links in your directory tree are inaccessible, because either link or target cannot be read by psacln or psaserv user groups.

To solve the issue,

1) Identify the symbolic links
# cd /var/www/vhosts
# find . -path ./system -prune -o -type l -ls
From the result you are only interested in the web space directories like /httpdocs, not the system directories like /logs, /chroot ...

2) Check and correct the permissions of links and targets. Targets must be accessible through appropriate permissions (typically 0755; use chmod for correction) and must either belong to USER psaserv or USER psacln groups (use chgroup for correction).

 

[G J Piper]

The symbolic links in your directory tree are inaccessible, because either link or target cannot be read by psacln or psaserv user groups.

To solve the issue,

1) Identify the symbolic links
# cd /var/www/vhosts
# find . -path ./system -prune -o -type l -ls
From the result you are only interested in the web space directories like /httpdocs, not the system directories like /logs, /chroot ...

2) Check and correct the permissions of links and targets. Targets must be accessible through appropriate permissions (typically 0755; use chmod for correction) and must either belong to USER psaserv or USER psacln groups (use chgroup for correction).

1) There are no symbolic links found (as expected, these are all real files it hits on -- static websites)
2) All files belong to psacln group.

I know... this is very strange why the symbolic link preference would cause this...

 

[Bitpalast]

... (as expected, these are all real files it hits on -- static websites) ...

Yes, but are these files owned by the user where the symbolic link is coming from? Example: A symbolic link from subscription A is pointing to a file in subscription B => That won't work, because the owner of the link target is different from the owner of the executing subscription. That is what the "restrict the ability to follow symbolic links" is meant for. It shall keep users from accessing files beyond their own webspace by using symbolic links. If the setting is turned on, the files that shall be accessed must be owned by the same user who is trying to access them.

 

[G J Piper]

Yes, but are these files owned by the user where the symbolic link is coming from? Example: A symbolic link from subscription A is pointing to a file in subscription B => That won't work, because the owner of the link target is different from the owner of the executing subscription. That is what the "restrict the ability to follow symbolic links" is meant for. It shall keep users from accessing files beyond their own webspace by using symbolic links. If the setting is turned on, the files that shall be accessed must be owned by the same user who is trying to access them.

There are no symbolic links anywhere.

Also keep in mind this was just upgraded from Plesk 12.5 yesterday -- maybe I forgot to mention that. The setting was the same before the upgrade with no problems as well.

 

[Bitpalast]

O.k., I see. New approach. What is the output of
# ps aux | grep nginx
and
# grep nginx /etc/group
?

 

[G J Piper]

O.k., I see. New approach. What is the output of
# ps aux | grep nginx
and
# grep nginx /etc/group
?

Here is my output. I think I might see where you're going with this...

# ps aux | grep nginx
root 22306 0.0 0.0 103308 872 pts/0 S+ 09:50 0:00 grep nginx
root 32242 0.0 0.4 64136 8676 ? Ss Mar17 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 32285 0.1 1.4 83996 31416 ? S Mar17 1:57 nginx: worker process

# grep nginx /etc/group
psaserv:x:502saadm,psaftp,apache,nginx
nginx:x:497:nginx

Should I add "psacln" to the nginx group? And, if I need to why didn't the Plesk installer do it?

lol I can't seem to keep the forum from turning colon-p into a toungue-out-happyface.

 

[Bitpalast]

All seems to be correct. Do not add psacln to the group, it is correct as it is.

If Nginx is run under nginx user (as it is) and part of psaserv group and if the files belong to the group, too, are real files and no links, it should work. I suggest to run
# plesk repair fs -v -y
to rule out issues with wrong file permissions in directories we are not considering at the moment.

I suggest, too, to restart Nginx. First test syntax
# nginx -t
and if that is good, restart
# service nginx restart
This shall make sure that no file handles are cached some place, pointing to non-existent locations.

 

[G J Piper]

All seems to be correct. Do not add psacln to the group, it is correct as it is.

If Nginx is run under nginx user (as it is) and part of psaserv group and if the files belong to the group, too, are real files and no links, it should work. I suggest to run
# plesk repair fs -v -y
to rule out issues with wrong file permissions in directories we are not considering at the moment.

I suggest, too, to restart Nginx. First test syntax
# nginx -t
and if that is good, restart
# service nginx restart
This shall make sure that no file handles are cached some place, pointing to non-existent locations.

# plesk repair fs -v -y
Checking Linux system files ......................................... [OK]
Checking virtual hosts' file system ................................. [OK]
Error messages: 0; Warnings: 0; Errors resolved: 0

# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

# service nginx restart
Starting nginx: [ OK ]


I turned back on the "restrict symbolic links" setting to see if any of this worked, and the errors began again for the domain I enabled it. Turning it back off.


I should also add... I have this in the "Additional nginx directives" for every domain:

add_header Strict-Transport-Security "max-age=31536000";
location ~ /\.ht {
deny all;
access_log off;
log_not_found off;
}
if ($scheme = http) {
return 301 https://$server_name$request_uri;
}

 

[Bitpalast]

I tried to recreate this setup on a test system, but could not reproduce the issue. I added your Nginx directives, too. In all cases, files are delivered correctly, no errors logged.

 

[G J Piper]

Maybe I can figure out if one of my custom settings is interfering.
What exactly does the "Restrict the ability to follow symbolic links" do in the back-end? What setting is it really changing/creating?