[unix] nginx error connect to php5-fpm.sock failed (13: Permission denied)

I update nginx to 1.4.7 and php to 5.5.12, After that I got the 502 error. Before I update everything works fine.

nginx-error.log

2014/05/03 13:27:41 [crit] 4202#0: *1 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: xx.xxx.xx.xx, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "xx.xx.xx.xx"

nginx.conf

user  www www;
worker_processes  1;

        location / {
            root   /usr/home/user/public_html;
            index  index.php index.html index.htm;
        }
        location ~ [^/]\.php(/|$) {
            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_index index.php;
            fastcgi_param  SCRIPT_FILENAME    /usr/home/user/public_html$fastcgi_script_name;
            include fastcgi_params;
        }

In fact, "listen.mode" should be: "0660" and not "0666" as Other Writable or Other Readable is never a good choice here.

So try to find out as which user/group your webserver runs. I use CentOs and it runs as user "nginx" So add to your php-fpm.conf:

listen.owner = nginx
listen.group = nginx
listen.mode = 0660

finally restart php-fpm

Please NOTICE (at least in centos 8) the user who you are assigning listen.owner and other stuff to it MUST be in the same POOL with the user for example given I am the foo user

[www] # WRONG | IN MY CASE I WAS UNDER www POOL SO IT WASNT WORKING FOR ME.
[foo] # CORRECT | THE POOL AND THE USER MATCHES.

listen.owner = foo
listen.group = foo
listen.mode = 0660
user = foo
group = foo

I dont know if there's a global pool but after hours of searching I finlly did it.

Alternative to broadening permissions in your php config, you could change the user specified in your nginx config.

On the first line of your nginx.conf excerpt above, the user and group are specified as www and www, respectively.

user  www www;

Meanwhile, your php config probably specifies a user and group of www-data:

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

You might change the line in your nginx.conf, to any of the following, then:

user www-data www;
user www-data www-data; # or any group, really, since you have the user matching
user www www-data; # requires that your php listen.mode gives rw access to the group

@Xander's solution works, but does not persist after a reboot.

I found that I had to change listen.mode to 0660 in /etc/php5/fpm/pool.d/www.conf.

Sample from www.conf:

; Set permissions for unix socket, if one is used. In Linux, read/write
; permissions must be set in order to allow connections from a web server. Many
; BSD-derived systems allow connections regardless of permissions. 
; Default Values: user and group are set as the running user
;                 mode is set to 0660
;listen.owner = www-data
;listen.group = www-data
;listen.mode = 0660

Edit: Per @Chris Burgess, I've changed this to the more secure method.

I removed the comment for listen.mode, .group and .owner:

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

/var/run Only holds information about the running system since last boot, e.g., currently logged-in users and running daemons. (http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure).

Side note:

My php5-fpm -v Reports: PHP 5.4.28-1+deb.sury.org~precise+1. The issue did happen after a recent update as well.

All the fixes currently mentioned here basically enable the security hole all over again.

What I ended up doing is adding the following lines to my PHP-FPM configuration file.

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

Make sure that www-data is actually the user the nginx worker is running as. For debian it's www-data by default.

Doing it this way does not enable the security problem that this change was supposed to fix.

Also check SELINUX (/etc/selinux):

# getenforce

turn it off:

# setenforce 0

I have fixed same issue on Amazon Linux AMI 2016.09 (Centos 7) by taking following steps.

Open your www.conf files (Example : sudo nano /etc/php-fpm.d/www.conf) Lastly, find the lines that set the listen.owner and listen.group and change their values from "nobody" to "nginx":

listen.owner = nginx
listen.group = nginx
listen.mode = 0666

Lastly, find the lines that set the user and group and change their values from "apache" to "nginx":

user = nginx
group = nginx

Restart php-fpm (sudo service php-fpm restart)

If you have declarations

pid = /run/php-fpm.pid

and

listen = /run/php-fpm.pid

in different configuration files, then root will owner of this file.

Just to add, on CentOS (and probably Red Hat and Fedora) the file to change the permissions to is at:

/etc/php-fpm.d/www.conf

In my case php-fpm wasn't running at all, so I just had to start the service

service php7.3-fpm start
#on ubuntu 18.04

After upgrading from Ubuntu 14.04 lts to Ubuntu 16.04 lts I found a yet another reason for this error that I haven't seen before.

During the upgrading process I had somehow lost my php5-fpm executable altogether. All the config files were intact and it took me a while to realize that service php5-fpm start didn't really start a process, as it did not show any errors.

My moment of awakening was when I noticed that there were no socket file in /var/run/php5-fpm.sock, as there should be, nor did netstat -an show processes listening on the port that I tried as an alternative while trying to solve this problem. Since the file /usr/sbin/php5-fpm was also non-existing, I was finally on the right track.

In order to solve this problem I upgraded php from version 5.5 to 7.0. apt-get install php-fpm did the trick as a side effect. After that and installing other necessary packages everything was back to normal.

This upgrading solution may have problems of its own, however. Since php has evolved quite a bit, it's possible that the software will break in unimaginable ways. So, even though I did go down that path, you may want to keep the version you're fond of just for a while longer.

Luckily, there seems to be a neat way for that, as described on The Customize Windows site:

add-apt-repository ppa:ondrej/php
apt-get purge php5-common
apt-get update
apt-get install php5.6

Neater solution as it might be, I didn't try that. I expect the next couple of days will tell me whether I should have.

Check which user runs nginx. As of Ubuntu 12.04 nginx runs by nginx user which is not a member of www-data group.

usermod -a -G www-data nginx

and restarting nginx and php5-fpm daemons solves the problem.

If you have different pool per user make sure user and group are set correctly in configuration file. You can find nginx user in /etc/nginx/nginx.conf file. nginx group is same as nginx user.

user = [pool-user]
group = [pool-group]
listen.owner = [nginx-user]
listen.group = [nginx-group]

The following simple fix worked for me, bypassing possible permissions issues with the socket.

In your nginx config, set fastcgi_pass to:

fastcgi_pass   127.0.0.1:9000;

Instead of

fastcgi_pass   /var/run/php5-fpm.sock;

This must match the listen = parameter in /etc/php5/fpm/pool.d/www.conf, so also set this to:

listen = 127.0.0.1:9000;

Then restart php5-fpm and nginx

service php5-fpm restart

And

service nginx restart

For more info, see: https://wildlyinaccurate.com/solving-502-bad-gateway-with-nginx-php-fpm/

The problem in my case was that the Nginx web server was running as user nginx and the pool was running as user www-data.

I solved the issue by changing the user Nginx is running at in the /etc/nginx/nginx.conf file (could be different on your system, mine is Ubuntu 16.04.1)

Change: user nginx;

to: user www-data;

then restart Nginx: service nginx restart

To those who tried everything in this thread and still stuck: This solved my problem. I updated /usr/local/nginx/conf/nginx.conf

1. Uncomment the line saying user

2. make it www-data so it becomes: user www-data;

3. Save it (root access required)

4. Restart nginx

Simple but works..

listen.owner = nginx
listen.group = nginx

chown nginx:nginx /var/run/php-fpm/php-fpm.sock

I did change OS on my server quite a few times trying to get the most comfortable system.

It used to work very well most of the time but lastly I got this 502 Gateway error.

I use a php fpm socket for each account instead of keeping the same one for all. So if one crashes, at least the other applications keep running.

I used to have user and group www-data. But this changed on my Debian 8 with latest Nginx 1.8 and php5-fpm.

The default user is nginx and so is the group. To be sure of this, the best way is to check the /etc/group and /etc/passwd files. These can't lie.

It is there I found that now I have nginx in both and no longer www-data.

Maybe this can help some people still trying to find out why the error message keeps coming up.

It worked for me.

Just see /etc/php5/php-fpm.conf pid = /var/run/php5-fpm.pid IS PID file

In file /etc/php5/fpm/pool.d/www.conf

listen = /var/run/php5-fpm.sock IS SOCKET file

if you pid equal listen (pid = /var/run/php5-fpm.sock and listen = /var/run/php5-fpm.sock) -> wrong settings and finish sett /etc/php5/fpm/pool.d/www.conf

user = nginx
group = nginx
listen.owner = nginx
listen.group = nginx
listen.mode = 0660

Consideration must also be given to your individual FPM pools, if any.

I couldn't figure out why none of these answers was working for me today. This had been a set-and-forget scenario for me, where I had forgotten that listen.user and listen.group were duplicated on a per-pool basis.

If you used pools for different user accounts like I did, where each user account owns their FPM processes and sockets, setting only the default listen.owner and listen.group configuration options to 'nginx' will simply not work. And obviously, letting 'nginx' own them all is not acceptable either.

For each pool, make sure that

listen.group = nginx

Otherwise, you can leave the pool's ownership and such alone.

The most important thing here is wich user is using nginx then do you need specify it as well

in your nginx.conf

user www-data;
worker_processes  1;

        location / {
            root   /usr/home/user/public_html;
            index  index.php index.html index.htm;
        }
        location ~ [^/]\.php(/|$) {
            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_index index.php;
            fastcgi_param  SCRIPT_FILENAME    /usr/home/user/public_html$fastcgi_script_name;
            include fastcgi_params;
        }

in your www.conf

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

in your case the user and group is "www" so just replace it.

• restart nginx and php fpm

I had the similar error.

All recommendations didn't help.

The only replacement www-data with nginx has helped:

$ sudo chown nginx:nginx /var/run/php/php7.2-fpm.sock

/var/www/php/fpm/pool.d/www.conf

user = nginx
group = nginx
...
listen.owner = nginx
listen.group = nginx
listen.mode = 0660

I just got this error again today as I updated my machine (with updates for PHP) running Ubuntu 14.04. The distribution config file /etc/php5/fpm/pool.d/www.conf is fine and doesn't require any changes currently.

I found the following errors:

dmesg | grep php
[...]
[ 4996.801789] traps: php5-fpm[23231] general protection ip:6c60d1 sp:7fff3f8c68f0 error:0 in php5-fpm[400000+800000]
[ 6788.335355] traps: php5-fpm[9069] general protection ip:6c5d81 sp:7fff98dd9a00 error:0 in php5-fpm[400000+7ff000]

The strange thing was that I have 2 sites running that utilize PHP-FPM on this machine one was running fine and the other (a Tiny Tiny RSS installation) gave me a 502, where both have been running fine before.

I compared both configuration files and found that fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; was missing for the affected site.

Both configuration files now contain the following block and are running fine again:

location ~ \.php$ {
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        include /etc/nginx/snippets/fastcgi-php.conf;
}

Update

It should be noted that Ubuntu ships two fastcgi related parameter files and also a configuration snippet which is available since Vivid and also in the PPA version. The solution was updated accordingly.

Diff of the fastcgi parameter files:

$ diff -up fastcgi_params fastcgi.conf
--- fastcgi_params      2015-07-22 01:42:39.000000000 +0200
+++ fastcgi.conf        2015-07-22 01:42:39.000000000 +0200
@@ -1,4 +1,5 @@

+fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
 fastcgi_param  QUERY_STRING       $query_string;
 fastcgi_param  REQUEST_METHOD     $request_method;
 fastcgi_param  CONTENT_TYPE       $content_type;

Configuration snippet in /etc/nginx/snippets/fastcgi-php.conf

# regex to split $uri to $fastcgi_script_name and $fastcgi_path
fastcgi_split_path_info ^(.+\.php)(/.+)$;

# Check that the PHP script exists before passing it
try_files $fastcgi_script_name =404;

# Bypass the fact that try_files resets $fastcgi_path_info
# see: http://trac.nginx.org/nginx/ticket/321
set $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;

fastcgi_index index.php;
include fastcgi.conf;

If you have tried everything in this post but are not having success getting PHP to work, this is what fixed it for my case:

Make sure you have these lines uncommented in /etc/php5/fpm/pool.d/www.conf:

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

Make sure /etc/nginx/fastcgi_params looks like this:

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  PATH_INFO          $fastcgi_script_name;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

These two lines were missing from my /etc/nginx/fastcgi_params, make sure they are there!

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  PATH_INFO          $fastcgi_script_name;

Then, restart php5-fpm and nginx. Should do the trick.