Are you seeing php-fpm.sock failed (13 permission denied) error in web server logs? We’ll help you fix it.
Often bad permissions or unavailability of the PHP-FPM handler results in these website errors.
Thus web server will not be able to communicate with the PHP FastCGI Process Manager or FPM.
At Bobcares, we resolve PHP-FPM errors as part of our Server Management Services.
Today, we’ll see how we resolve php-fpm.sock failed error and make websites working.
Where do we see php-fpm.sock failed (13 permission denied) error?
PHP FastCGI Process Manager (PHP-FPM) is a popular way of handling PHP pages. It allows a website to handle high loads. And, it works very well with high traffic websites too.
Usually, the php-fpm socket failure errors show up in the web server error logs as:
[crit] 4596#0: *138 connect() to unix:/tmp/php-fpm.sock failed (13: Permission denied) while connecting to upstream
On the website page, this would result in errors like 502 Bad Gateway or 503 Service Temporarily Unavailable.
Top causes for php-fpm.sock failed (13 permission denied) error
In general, PHP-FPM maintains a set of pools. These pools are workers available to respond to PHP requests. They will only execute PHP scripts as per the web server’s request. Finally, it sends the result back to the webserver. Thus, enabling PHP-FPM to service content will be quicker than usual methods.
However, when the webserver cannot communicate with the FPM handler, it eventually results in website errors.
Now, let’s see the top reasons for the PHP FPM socket failure.
One of the common reasons for the PHP FPM failure will be related permissions. When the permissions are wrong, the Apache or Nginx server will not be able to connect to the FPM daemon.
Recently, when a customer updated the PHP packages on his server, it reset the permissions of the files. The php-fpm socket was created with wrong ownership. Thus, the Nginx was not able to connect to the php-fpm socket.
The correct socket file permissions should be
Often, extended access control lists also restrict access to the directory in which the socket lies. Thus, it makes php-fpm inaccessible for the web user.
Failed PHP-FPM service
Similarly, a failure in the PHP FPM service also can cause php-fpm.sock failed (13 permission denied) error.
In a cPanel server, a failed status of the cpanel_php_fpm status shows up as:
This can be related to an incorrect php-fpm configuration or wrong server settings. Likewise, insufficient server memory can also prevent the start-up of php-fpm.
How we fix php-fpm.sock failed (13 permission denied) error
Moving on, let’s see how our Support Engineers fix the PHP FPM socket errors and make website working.
We begin by checking the status of the FPM status. On a cPanel server, we check it by using the command:
service cpanel_php_fpm status
If it is not running, we simply restart it.
/scripts/restartsrv_cpanel_php_fpm --stop /scripts/restartsrv_cpanel_php_fpm --start
Next, we check the error logs at /usr/local/cpanel/logs/php-fpm/error.log
It will show up any type of configuration errors. We correct these errors and make fpm running again. Here, we also check the memory usage of the server. Then add more memory in case of any resource constraints.
Correcting permissions of the socket
To fix the permissions of the socket file on an Nginx server, we did the following steps.
Edited the /etc/php-fpm.d/www.conf file and corrected these variables:
listen = /tmp/php7-fpm.sock listen.owner = nginx listen.group = nginx
Here, the webserver was running under the user nginx. So we set the php-fpm user as nginx itself. Then, we saved the file and restarted PHP FPM
sudo service php7-fpm restart
This corrected the permissions on the socket file.
[firstname.lastname@example.org:~]ls -ahl /tmp/php7-fpm.sock srw-rw---- 1 nginx nginx 0 Apr 6 08:08 /tmp/php7-fpm.sock
Finally, the website started working again.
[Need help to fix PHP FPM errors? We are available 24×7.]
In short, php-fpm.sock failed (13 permission denied) error happens due to incorrect PHP FPM configuration or service failure. Today, we saw how our Support Engineers fix the socket permissions and make the websites working.