Issue PHP instances running as non-existent users

[UnS3eN]

Getting a weird issue on ‪CentOS 6.9 / Plesk Onyx Version 17.0.17 Update #27.

For some sites php is running as a non-existent system user and as a result we're having issues with folder permissions.

[(15:48:46) root@plesk /var/www/vhosts]# ps aux | grep php
...
mot##### 7823 12.4 2.4 429480 95788 ? SN 15:49 0:03 /opt/plesk/php/5.6/bin/php-cgi -c /var/www/vhosts/system/site1/etc/php.ini
djc##### 7830 11.4 2.0 407632 81200 ? SN 15:49 0:01 /opt/plesk/php/5.6/bin/php-cgi -c /var/www/vhosts/system/site2/etc/php.ini
djc##### 7831 18.1 1.9 404092 75888 ? SN 15:49 0:01 /opt/plesk/php/5.6/bin/php-cgi -c /var/www/vhosts/system/site2/etc/php.ini
10001 <- 7833 17.8 1.6 404236 63376 ? SN 15:49 0:01 /opt/plesk/php/5.6/bin/php-cgi -c /var/www/vhosts/system/site3/etc/php.ini
10013 <- 7834 13.7 1.1 396732 43808 ? SN 15:49 0:00 /opt/plesk/php/5.6/bin/php-cgi -c /var/www/vhosts/system/site4/etc/php.ini
...

The 10001 and 10013 should be the actual site owners like the other two (red), but they are

[(15:52:57) root@plesk /var/www/vhosts]# groups 10001
groups: 10001: No such user

[(15:53:00) root@plesk /var/www/vhosts]# groups 10013
groups: 10013: No such user

/var/www/system/site/etc/conf/httpd.conf look the same for all sites (with reasonable path/user differences)

Is there a way to change the user that runs a particular instance of php?

 

[UFHH01]

Hi UnS3eN,

did you consider to try the "Plesk Repair Utility", with the option "fs" ?

=> Plesk Repair Utility: File System​

Example commands:

plesk repair fs -n -v

Just to DISPLAY detected issues.

plesk repair fs -y -v

Automatically repair detected issues​

 

[UnS3eN]

[(16:38:46) root@plesk /var/www/vhosts]# plesk repair fs -n -v

Checking Linux system files ......................................... [OK]

Checking virtual hosts' file system

  There are files or directories with suspicious permissions in the
  root directory of the domain 'billing.domain.com' ..................... [WARNING]
    - /var/www/vhosts/domain.com/billing.domain.com/configuration.php

  There are incorrect permissions on some items in the WWW root
  directory of the domain 'site3' .............................. [ERROR]
    - Incorrect permissions on /var/www/vhosts/site3/httpdocs/.:
      expected is one of 0750, 0755, actual is 0775

  There are incorrect permissions on some items in the WWW root
  directory of the domain 'site4' ....................... [ERROR]
    - Incorrect permissions on
      /var/www/vhosts/site4/httpdocs/.: expected is one
      of 0750, 0755, actual is 0775

Error messages: 2; Warnings: 1; Errors resolved: 0


exit status 1

This is nothing major, 775 vs 755 in this case is not gonna make any difference. The issue is the PHP instance is not run as the site owner, but some temp user that doesn't even exist on the system.

Just to humour you:

[(18:32:30) root@plesk /var/www/vhosts]# plesk repair fs -y -v

Checking Linux system files ......................................... [OK]

Checking virtual hosts' file system

  There are files or directories with suspicious permissions in the
  root directory of the domain 'billing.domain.com' ..................... [WARNING]
    - /var/www/vhosts/domain.com/billing.domain.com/configuration.php

  There are incorrect permissions on some items in the WWW root
  directory of the domain 'site3' .............................. [ERROR]
    - Incorrect permissions on /var/www/vhosts/site3/httpdocs/.:
      expected is one of 0750, 0755, actual is 0775
    Repairing incorrect permissions ................................. [FIXED]

  There are incorrect permissions on some items in the WWW root
  directory of the domain 'site3' ....................... [ERROR]
    - Incorrect permissions on
      /var/www/vhosts/site3/httpdocs/.: expected is one
      of 0750, 0755, actual is 0775
    Repairing incorrect permissions ................................. [FIXED]

Error messages: 2; Warnings: 1; Errors resolved: 2

That made absolutely no difference site access wise and PHP is still run as non-existent users for those 2 sites:

[(18:39:39) root@plesk /var/www/vhosts/]# ps aux | grep php
...
mot##### 18404  0.5  0.6 393524 25732 ?        S    18:39   0:00 /opt/plesk/php/5.6/bin/php-cgi -c /var/www/vhosts/system/site1/etc/php.ini
10001 <- 18405  4.7  1.6 406572 63180 ?        S    18:39   0:01 /opt/plesk/php/5.6/bin/php-cgi -c /var/www/vhosts/system/site1/etc/php.ini
10001 <- 18406  4.8  1.5 403536 62328 ?        S    18:39   0:01 /opt/plesk/php/5.6/bin/php-cgi -c /var/www/vhosts/system/site1/etc/php.ini
djc##### 18407  7.1  1.9 406160 76328 ?        S    18:39   0:02 /opt/plesk/php/5.6/bin/php-cgi -c /var/www/vhosts/system/site2/etc/php.ini
mot##### 18408  9.8  2.0 412908 81704 ?        S    18:39   0:02 /opt/plesk/php/5.6/bin/php-cgi -c /var/www/vhosts/system/site1/etc/php.ini
10013 <- 18412 17.3  1.1 396940 44024 ?        S    18:39   0:01 /opt/plesk/php/5.6/bin/php-cgi -c /var/www/vhosts/system/site4/etc/php.ini
...

The issue is not the file system. The issue is that PHP instances as misconfigured

 

[UFHH01]

Hi UnS3eN,

The issue is not the file system. The issue is that PHP instances as misconfigured

well, ... NO. The numbers instead of the correct group/user is an indication, that you have some database inconsistency, where the root cause could be unfinished renamings or incorrect migration processes and the root cause could be as well incorrect permissions BEFORE renamings and migrations.

Consider to read => Virtual Host Structure (Linux) to inform you about the correct permissions, when you use Plesk on your server.


I suggest to manually change the folders with the correct group and domain-specific system-user ( which should be existent at "/etc/group" and "/etc/passwd" ), starting at the folder "/var/www/vhosts".

 

[UnS3eN]

...
I suggest to manually change the folders with the correct group and domain-specific system-user ( which should be existent at "/etc/group" and "/etc/passwd" ), starting at the folder "/var/www/vhosts".

Done that again and again. Double, triple and quadruple checked user:group permissions are correct for folders/files. Still getting the same. Repeated the same migration process for several more sites - some migrated OK, some not.

At this point I'm pretty certain permissions are OK.

Making sure the user and group exist:

# cat /etc/passwd
...
<USER>:x:10014:503::/var/www/vhosts/<SITE>:/bin/false
...

# groups <USER>
<USER> : psacln

# cat /etc/group
...
psacln:x:503:
...

Confirming .../vhosts/system/<SITE> permissions are OK. Never went near them after creating the subscription anyway.

[(13:08:06) root@plesk /var/www/vhosts/system/<SITE>]# ls -la
total 28
drwx--x--x   7 root   psaserv 4096 Jun 22 12:20 .
drwxr-xr-x. 19 root   root    4096 Jun 22 12:43 ..
drwxr-x---   2 root   psaserv 4096 Jun 22 12:26 conf
drwxr-xr-x   2 root   root    4096 Jun 22 12:20 etc
drwx------   2 psaadm root    4096 Jun 22 12:20 logs
drwx--x---   2 root   psaserv 4096 Jun 22 12:26 pd
dr-xr-x---   6 root   psaserv 4096 Jun 22 12:20 statistics

chmod 755 /var/www/vhosts/<SITE>

[(13:09:57) root@plesk /var/www/vhosts]# ls -la
total 84
...
drwxr-xr-x   5 <USER>        psaserv 4096 Jun 22 12:20 <SITE>
...

Seems OK here as well:

[(13:11:26) root@plesk /var/www/vhosts/<SITE>]# ls -la
total 20
drwx--x---   5 <USER> psaserv 4096 Jun 22 12:20 .
drwxr-xr-x. 21 root      root    4096 Jun 22 12:43 ..
drwxr-xr-x   2 <USER> psacln  4096 Jun 22 12:20 error_docs
drwxr-x---   7 <USER> psaserv 4096 Jun 22 12:32 httpdocs
drwx------   2 <USER> root    4096 Jun 22 12:20 logs

.../vhosts/<SITE>/httpdocs]# chown -R <USER> : psacln *
.../vhosts/<SITE>/httpdocs]# chmod -R 755 *

[(13:13:24) root@plesk /var/www/vhosts/<SITE>/httpdocs]# ls -la
total 212
drwxr-x---  7 <USER> psaserv  4096 Jun 22 12:32 .
drwx--x---  5 <USER> psaserv  4096 Jun 22 12:20 ..
-rwxr-xr-x  1 <USER> psacln    418 Jun 22 12:25 index.php
-rwxr-xr-x  1 <USER> psacln  19935 Jun 22 12:25 license.txt
-rwxr-xr-x  1 <USER> psacln   7433 Jun 22 12:25 readme.html
-rwxr-xr-x  1 <USER> psacln     14 Jun 22 12:25 robots.txt
drwxr-xr-x  2 <USER> psacln   4096 Jun 22 12:27 stats
...

I don't see any thing wrong here. Yet still:

# ps aux | grep php
...
10014     4397  7.8  1.6 406044 63464 ?        SN   13:32   0:01 /opt/plesk/php/5.6/bin/php-cgi -c /var/www/vhosts/system/<SITE>/etc/php.ini
10014     4398  7.0  1.5 402188 61908 ?        SN   13:32   0:00 /opt/plesk/php/5.6/bin/php-cgi -c /var/www/vhosts/system/<SITE>/etc/php.ini
...

 

[UFHH01]

Hi UnS3eN,

the Plesk documentation informs you about the recommended permissions at:

=> Virtual Host Structure (Linux)​

If you desire own ( modified ) permissions, pls. set it on your own risk and without Plesk support.


I can't really follow your manual modifications and why you change it, but I would like to point you to the fact ( from your provided informations ), that the domain - specific - system user now owns the process for the domain - specific PHP - process:

10014 => <USER>:x:10014:503::/var/www/vhosts/<SITE>:/bin/false​

... and you should see the username instead of the depending user-number, when you use a new SSH - login.

Depending to your server and it's possible kernel updates/upgrades, you should consider to reboot your server and pls. start over your investigations, as you did it in your first post, if you still experience issues/errors/problems.

 

[UnS3eN]

The manual permissions are as per => Virtual Host Structure (Linux) like you said twice. The problem is, even if the permissions set are correct the issue doesn't go away. This is frustrating as the only way I found to resolve this is to delete and start over, and hope it works fine this time around.

...
I can't really follow your manual modifications and why you change it...

I have to do that is because I can't extract .tar.gz files from Plesk's file manager as Plesk doesn't recognise it as an archive.

Unable to extract /httpdocs/archive.tar.gz: The file is not an archive.

So I end up SSHing into Plesk and extracting the files manually. They don't have the correct owner or permissions upon extraction, thus the manual changes as per vHost structure tables.