php-fpm support for nginx not starting / working - permission denied issue - fixed

[ashley]

Centos 7, Plesk 12

Problem:

PHP-FPM support for nginx will not start when attempted in Tools & Settings > Services Management


Check error log:

#tail /var/log/php-fpm/error.log

ERROR: unable to bind listening socket for address '/var/www/vhosts/system/domain.tld/php-fpm.sock': Permission denied (13)


Possible problem:

SELinux may be preventing it. To test this do:

#setenforce 0

Now try and start PHP-FPM support again in Tools & Settings > Services Management

If that now starts you know what the problem is. Go to "Fix" below
If it didnt work, you have a different issue. Turn SELinux back on while you figure it out:

#setenforce 1


Fix:

The following worked for me but i know very little about SELinux - corrections welcome:

## Turn SELinux to permissive
# setenforce 0

## In Plesk panel start PHP-FPM support in Tools & Settings > Services Management

# grep php-fpm /var/log/audit/audit.log | audit2allow -m php-fpmlocal > php-fpm.te

## You can vi/cat/nano php-fpm.te and see the custom policy that will be created. When done, execute it with:

# grep php-fpm /var/log/audit/audit.log | audit2allow -M php-fpmlocal

## now load the policy
# semodule -i php-fpmlocal.pp

## Turn SElinux back on
#setenforce 1

## In Plesk panel start PHP-FPM support in Tools & Settings > Services Management

## Still not working. Sorry - good luck finding the problem.

Reference page
http://wiki.centos.org/HowTos/SELinux

 

[UFHH01]

Hi ashley,

please have a look at the Parallels KB - article, which handles your issue:

Webserver reconfiguration fails with permission denied when SELinux is in enforced mode ( KB - article 115 299 )​

 

[ashley]

While useful perhaps for someone with that issue, it is not really relevant to the specific issue i had, nor based on the same error messages shown. When i was looking for help with the problem, Google didn't really help. In fact, 6 hours of paid SWSoft support couldn't figure it out. When i realised it was an SELinux issue, SWSoft support told me to disable SELinux totally and would offer no further assistance. So i hope this is useful for someone else Googling it and before paying for support or getting told to disable their security protection in entirety.

 

[UFHH01]

Hi ashley,

you might have a CLOSER look on the resolution, instead of the described symptoms, because YOUR work-around is to modify the SELinux security contexts. Before declaring it as "not functional suggestion", I think it might be a good idea to give it a try and report afterwards, if it might suit your needs.

 

[ashley]

I will try and spin up another machine and test when i get time. Perhaps in the meantime you could highlight why my solution is a bad idea so those reading can be more secure etc. Thanks.

 

[UFHH01]

Hi ashley,

please compare YOUR additional contexts with the one you create while sticking to the Parallels suggestion and you will notice the specific differences on your own.

 

[ashley]

As stated I know little of SELinux and im time poor. Im guessing that the command you suggest is adding security context to the /var/www/vhosts/[^/]*/conf(/.*)? . If that is the case, I don’t think it would help since I need to create a socket in /var/www/vhosts/system/domain.tld/. So if you are saying there is a better option or the solution I provided is deficient or insecure it would be kind if you could clarify for me and others who find themselves here.

Thanks

 

[UFHH01]

Hi ashley,

please... again... have a CLOSER look, because it's farely useless to explain the suggestion, if the basic knowledge is still missing. The domain/subdomain - "conf" - folders include all webserver - configurations for apache and nginx and as well include in depending domain/subdomain - specific paths ... and yes, as well the path for the domain/subdomain - specific php-fpm - socket and php.ini. The suggested SELinux contexts from the Parallels KB - article will then include all domain/subdomain - specific configurations and paths, which is not the case, if you just try to add the domain/subdomain - specific socket.

 

[ashley]

You still dont say whether there is a problem doing what i did. The KB approach as you say is to blanket allow. My thinking on security is to enable as little as required which is what i did.

 

[UFHH01]

Hi ashley,

well... I'm not here in the forums, to discuss issues... I rather stick to help investigating issues/problems with Plesk and suggesting solutions and work-arounds. If you desire to modify your very own security contexts with a thought of "as little as required", without using the suggestions from the Parallels Team who invented and coded Plesk.... it's absolutely your choice. It's absolutely your choice, if you are going to modify/add your contexts again and again and again, because the "little as required" was far too less, because you didn't include paths and configurations within a domain... again... it's absolutely your choice - feel free to do whatever you would like to - you might think again about the suggestion, when you changed/added/modified your contexts for a fifth or more time, because they didn't fit your needs.