$ guides / php-fpm / php-fpm-socket-permission-denied ▌

Operations Guides

PHP-FPM "connect() to unix:/... failed (13: Permission denied)": socket ownership

The nginx error connect() to unix:/var/run/php/php-fpm.sock failed (13: Permission denied) is a Unix socket ownership problem between the web server and PHP-FPM. Every PHP request returns 502 while static assets serve fine. The PHP-FPM master is up, the socket file exists, workers are idle, and yet no traffic flows.

The (13: Permission denied) suffix is errno 13, EACCES. nginx calls connect(2) on the socket path and the kernel rejects it before any FastCGI bytes are exchanged. The cause is on the socket inode or on a parent directory, not in the FastCGI protocol, the application, or pool sizing.

This article covers how to identify which of the three usual suspects is responsible (socket ownership and mode, parent directory traversal, or MAC policy), how to fix each without restarting more than necessary, and how to keep package upgrades from silently resetting the socket back to root:root.

What this means

For a Unix domain socket, connect(2) requires write permission on the socket inode. EACCES from connect() means the inode exists and is reachable, but the calling process’s UID and supplementary GIDs do not grant write access through the file’s permission bits. Three preconditions must hold for the web server worker to connect:

The web server user (commonly nginx, www-data, or apache) must have write permission on the socket file itself.
The web server user must have execute (search) permission on every directory in the path to the socket.
No mandatory access control system (SELinux in enforcing mode, AppArmor in enforce mode) can be denying the connect.

All three failure modes produce the same (13: Permission denied) line in nginx, and they are not distinguishable from the error string alone.

The PHP-FPM pool directives that control the first precondition are listen.owner, listen.group, and listen.mode. When listen.owner and listen.group are unset (as they ship commented out in the upstream www.conf.in template), PHP-FPM creates the socket owned by the master process user, which on package-managed installs is typically root. With the default listen.mode = 0660, the web server user cannot write to the socket because it is neither root nor in root’s primary group.

PHP-FPM tightened its default socket mode to 0660 as a privilege boundary fix. Any deployment that relied on the older permissive default must now explicitly set listen.owner and listen.group to the web server user.

Common causes

Cause	What it looks like	First thing to check
`listen.owner` / `listen.group` mismatch	Socket owned by `root` or by the FPM pool user instead of the web server user	`ls -l /path/to/socket`
`listen.mode` too restrictive	Socket mode is `0660` or `0640` while the web server is not in the owning group	`ls -l` mode bits on the socket
`listen.acl_users` exclusion	Socket has POSIX ACLs that do not list the web server user	`getfacl /path/to/socket`; `php-fpm -tt` for effective config
Parent directory not traversable	Socket perms look fine but nginx still gets EACCES	`namei -l /path/to/socket`
SELinux AVC denial	All Unix perms correct, audit log shows AVC against the socket	`ausearch -m AVC -ts recent`
AppArmor denial	All Unix perms correct, syslog or audit shows `DENIED`	`dmesg \| grep apparmor`
Post-upgrade reset	Started immediately after a `php*` package upgrade	Diff pool `.dpkg-dist` / `.rpmnew` files

Quick checks

These are all read-only. None touch the FPM master or the socket inode.

# Identify the web server user
ps -o user= -C nginx -C apache2 -C httpd | sort -u

# Inspect the socket inode
ls -l /var/run/php/php-fpm.sock

# Check every parent directory for traverse (x) permission
namei -l /var/run/php/php-fpm.sock

# Confirm FPM is actually listening on this path
ss -xlnp | grep php

# Confirm nginx upstream matches FPM listen path
grep -R "fastcgi_pass.*unix:" /etc/nginx/

# Dump the effective FPM pool config without starting the daemon
php-fpm -tt 2>&1 | grep -E "listen|user|group"

# Check POSIX ACLs on the socket
getfacl /var/run/php/php-fpm.sock

# Look for recent SELinux AVC denials
sudo ausearch -m AVC -ts recent 2>/dev/null | tail -50

# Look for recent AppArmor denials
sudo dmesg | grep -i 'apparmor.*DENIED' | tail -20

# Verify the web server user can stat the socket
sudo -u www-data test -e /var/run/php/php-fpm.sock && echo OK || echo DENIED

How to diagnose it

The diagnostic flow is short. The error string tells you the socket exists, so the question is which of the three preconditions is failing.

flowchart td
  A["nginx logs (13: Permission denied)"] --> B{"ls -l socket"}
  B -->|"owner != web server user"| C["listen.owner/group wrong"]
  B -->|"owner OK"| D{"namei -l shows x for web server?"}
  D -->|"no"| E["parent dir traverse denied"]
  D -->|"yes"| F{"ausearch / dmesg shows AVC?"}
  F -->|"yes"| G["SELinux or AppArmor"]
  F -->|"no"| H["check listen.acl_users / getfacl"]

Confirm the exact socket path nginx is trying to use by grepping the nginx config for fastcgi_pass unix:. Cross-check against ss -xlnp | grep php to confirm FPM is listening on that exact path. A path mismatch produces (2: No such file or directory) rather than (13: Permission denied), but it is worth eliminating early.
Run ls -l on the socket. If the owner is root and the mode is 0660, this is the classic case: listen.owner and listen.group are unset in the pool config, so the socket inherits the master process user. If the owner is the FPM pool user (for example www-data) but the web server user is different (for example nginx), you have a user-mismatch case rather than a missing-directive case.
Run namei -l /path/to/socket. Every parent directory must show x permission for the web server user, the web server group, or other. A socket under /root/, under a non-world-traversable application directory, or under a 0750 directory owned by another user will produce EACCES even if the socket itself is 0666.
Run php-fpm -tt (test mode) and grep for listen.owner, listen.group, listen.mode, and listen.acl_users. This shows the effective pool configuration after includes. When listen.acl_users is set, PHP-FPM applies POSIX ACLs to the socket granting connect access to the listed users. The web server user must appear in that list or already have access via listen.owner/listen.group. Use getfacl on the live socket to verify what ACLs are actually in effect.
If everything Unix-level looks correct, check MAC. On RHEL-family systems, sudo ausearch -m AVC -ts recent shows SELinux denials. On Debian/Ubuntu with AppArmor, sudo dmesg | grep -i apparmor shows DENIED entries. The nginx error string is identical in both cases.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
nginx 5xx rate on PHP endpoints	First user-visible symptom of EACCES	Sustained 502 spike with no upstream timeout
PHP-FPM `accepted conn` rate	Drops to zero if the web server cannot deliver connections	Rate flatlines at zero while web server logs show 502s
PHP-FPM ping endpoint response	Tests the FPM listener path in isolation	Ping succeeds (master alive) while web server still gets EACCES
Socket file owner and mode drift	Detects post-upgrade permission reset	Owner changes from `www-data` to `root` after `apt upgrade`
SELinux AVC rate	Surfaces silent MAC denials	New AVC entries correlated with web server errors
`php-fpm -tt` config diff	Detects pool config drift	Effective values change after a package upgrade

Fixes

Match listen.owner / listen.group / listen.mode to the web server user

In the affected pool config (commonly /etc/php/*/fpm/pool.d/www.conf on Debian/Ubuntu or /etc/php-fpm.d/www.conf on RHEL-family systems):

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Replace www-data with nginx or apache to match your web server user. Then reload PHP-FPM. On systemd-managed installs, use the exact service name (for example systemctl reload php8.2-fpm), or send SIGUSR2 to the master process. SIGUSR2 triggers a graceful reload where the master re-execs and workers drain, so expect a brief window where the socket is unavailable. Use systemctl restart only if reload does not pick up the new socket ownership.

Do not use listen.mode = 0666 as a workaround. It opens the socket to every local user, including unprivileged accounts that should not be able to submit FastCGI requests.

Fix parent directory traversal

Move the socket to a directory the web server user can traverse. The conventional location on Debian/Ubuntu is /run/php/ (which is world-traversable), and on RHEL-family systems it is /run/php-fpm/ or /var/run/php-fpm/. Update both listen = /run/php/...sock in the FPM pool config and fastcgi_pass unix:/run/php/...sock; in nginx.

If you must keep the socket in a non-standard location, ensure every parent directory has 0755 mode or grants x to the web server user explicitly through ACLs.

Handle listen.acl_users

When listen.acl_users is set, PHP-FPM applies POSIX ACL entries to the socket in addition to the base owner/group/mode. The web server user needs to appear in the ACL list or be granted access via listen.owner/listen.group. If the socket stays inaccessible despite setting listen.owner, check getfacl on the live socket and php-fpm -tt for the effective listen.acl_users value. Either add the web server user to the list:

listen.acl_users = nginx,apache,www-data

Or remove listen.acl_users from the pool config so only listen.owner, listen.group, and listen.mode apply. listen.acl_users is not an alternative file mode: it adds user ACL entries, while PHP-FPM logs that any configured listen.owner or listen.group is ignored when ACLs are set. Verify with getfacl /path/to/socket after reload.

SELinux denials

If ausearch shows an AVC denial for the web server process against the socket, the typical fixes are:

# Restore the expected SELinux context on the socket path
sudo restorecon -Rv /run/php/
# Or set the httpd_unified boolean (broadens access significantly)
sudo setsebool -P httpd_unified 1

The narrower fix is to read the AVC’s target object and permission, confirm the current label with ls -Zd /run/php/ and ls -lZ /run/php/*.sock, then place the socket in a path the installed policy already labels correctly or create a focused local policy module. Avoid httpd_unified unless you understand the trade-off: it grants the httpd domain broad access across many file types and weakens the SELinux boundary.

AppArmor denials

AppArmor denials appear in dmesg and /var/log/syslog or /var/log/audit/audit.log as apparmor="DENIED". The fix is to update the offending profile (usually the php-fpm or nginx profile) to allow the socket path, or to switch the profile to complain mode while you investigate:

sudo aa-complain /usr/sbin/php-fpm*

Complain mode logs rather than blocks, which is useful for confirming the profile is the cause before editing it. Do not leave profiles in complain mode in production longer than necessary.

When nginx and PHP-FPM run in separate containers sharing a socket via a mounted volume, UID/GID values must match across containers. A user named www-data in the nginx image may have UID 33, while in the PHP-FPM image the same name may map to a different UID. The kernel checks numeric UIDs, not names.

Either build both images with explicit matching USER 33 directives, or set the socket owner and mode to values that both containers’ actual numeric UIDs can satisfy. Avoid listen.mode = 0777 to paper over the mismatch: it allows any process in either container’s namespace to submit FastCGI requests.

Prevention

Pin pool config in configuration management. The most common cause of recurrence is a package upgrade dropping a new www.conf that resets listen.owner and listen.group back to commented-out defaults. Ansible, Puppet, Chef, or Salt should own these files end to end.
Use dpkg-statoverride or rpm verification. On Debian-family systems, dpkg-statoverride records intentional permission changes and reapplies them across upgrades. This is most useful for the socket directory, not the socket file itself (which is recreated on every FPM start). On RHEL-family systems, rpm -V flags when a packaged config file has been modified or overwritten.
Monitor socket ownership. A check that alerts when the socket owner drifts from the web server user catches post-upgrade resets before the next user-facing 502.
Add a startup smoke test. After every FPM reload, run a single FastCGI ping from the web server user (sudo -u www-data cgi-fcgi -bind -connect /run/php/...sock, requires the libfcgi-bin or fcgi package) and fail loudly if it cannot connect. This catches permission regressions before real traffic is affected.
Diff after package upgrades. Treat any php* package upgrade as a trigger to verify listen.owner, listen.group, listen.mode, and listen.acl_users are still set as intended.

How Netdata helps

Per-second nginx 5xx rate alongside PHP-FPM accepted connection rate. A socket permission failure produces a specific signature: nginx 502 rate spikes on PHP endpoints while FPM’s accepted conn counter flatlines at zero. The decoupling is immediate and visible at one-second resolution.
PHP-FPM status page polling. The ping endpoint succeeds (master is alive, socket is listening) while PHP request traffic is zero. This pattern distinguishes a permission failure from an FPM crash, an OOM kill, or pool exhaustion.
Process and file descriptor metrics for php-fpm. Workers are present and idle, ruling out pool exhaustion and crash loops as the cause of the 502s.
Correlation with package upgrade events. A permission failure that begins immediately after a php* package install or upgrade is the textbook post-upgrade reset, and timestamp correlation narrows the search dramatically.