Hello, I'm running ISPConfig with Nginx and PHP 8.3/8.4 on Ubuntu Server. After upgrading to ISPConfig 3.3.1p1 I started noticing `[crit] openat() failed (13: Permission denied)` errors in the Nginx error log, appearing exactly twice for every `GET / HTTP/2.0` request on all hosted WordPress sites. All other routes were unaffected. After investigation, the root cause turned out to be a combination of two things: 1. ISPConfig 3.3.1 sets the web root directory permissions to `710` (previously `711`), which is the security hardening introduced in this release. 2. The Nginx worker (`www-data`) is correctly a member of my client group, so it has execute (`--x`) on the web root — enough to traverse into it and serve named files — but not read (`r-x`), which Nginx requires when evaluating `try_files $uri/` (i.e., attempting to open the directory itself as an object). This causes Nginx to fail the `try_files` directory check twice per request (for `$uri` and `$uri/`) before falling back to `index.php`, generating two `openat()` permission denied errors per page load. The errors are non-fatal but pollute the logs and indicate a real permission gap. The fix is to set the web root to `750` instead of `710`, which grants the group both read and execute: 1. Was the change from `711` to `710` intentional as a security measure in 3.3.1? If so, was the corresponding group read permission (`750` vs `710`) considered for setups where the web server user shares the client group? 2. Should ISPConfig set the document root to `750` rather than `710` when the Nginx/Apache user is a member of the site's client group? `710` effectively breaks `try_files $uri/` for the web server user. 3. Is there a supported way to configure the web root permissions in ISPConfig's server config so this survives resync and site recreation, rather than having to manually fix permissions after every site change? Happy to provide additional logs or config details if useful. Thanks.
Yes, it's intentional. What a funny question btw, do you really think we change major folder permissions unintentionally out of the blue on a few hundred thousand servers, just for fun? It shall be set to 710, which works fine here on Apache and Nginx. If you use a non-standard setup, then you can configure the permission. See System > Server config. Never manually alter any permissions.
Hello Till, thank you for your reply (happy to give you a little fun ). Do you have any suggestions to avoid filling nginx error logs with openat() errors due to classic Wordpress Nginx try_file directive, other than changing webroots permissions through Server config? Thanks again.
