PhpMyAdmin read access and open_basedir restrictions error (nginx, php7.1, ubuntu 17.10)

/var/log/nginx/error.log lists the following error messages while browsing to server:8081/phpmyadmin:

Code:

[error] 942#942: *1366 FastCGI sent in stderr: "PHP message: phpmyadmin: Failed to load /var/lib/phpmyadmin/blowfish_secret.inc.php Check group www-data has read access and open_basedir restrictions.
PHP message: phpmyadmin: Failed to load /var/lib/phpmyadmin/config.inc.php Check group www-data has read access and open_basedir restrictions.
PHP message: phpmyadmin: Failed to load /etc/phpmyadmin/config-db.php Check group www-data has read access and open_basedir restrictions" while reading response header from upstream, client: <ip-removed>, server: _, request: "GET /phpmyadmin/ HTTP/1.1", upstream: "fastcgi://unix:/var/lib/php7.1-fpm/apps.sock:", host: "<ip-removed>:8081"

Yet, there are no warnings in the browser; phpmyadmin login prompt displays fine and accepts the login. The error messages keep coming while browsing through phpmyadmin though.

Checking the file permissions, they are already owned by www-data

Code:

~# ll /var/lib/phpmyadmin/    
total 16                                         
drwxr-xr-x  3 root     root     4096 Apr 26 19:53 ./                                               
drwxr-xr-x 61 root     root     4096 Apr 27 09:22 ../                                              
-rw-r-----  1 root     www-data   68 Apr 26 19:53 blowfish_secret.inc.php                          
-rw-r-----  1 root     www-data    0 Apr 26 19:53 config.inc.php                                   
drwxr-xr-x  2 www-data www-data 4096 Jul 10  2017 tmp/                                             
~# ll /etc/phpmyadmin/        
total 60                                         
drwxr-xr-x   3 root root      4096 Apr 27 17:55 ./
drwxr-xr-x 127 root root     12288 Apr 28 06:01 ../                                                
-rw-r--r--   1 root root      2110 Jul 10  2017 apache.conf                                        
drwxr-xr-x   2 root root      4096 Jul 10  2017 conf.d/                                            
-rw-r-----   1 root www-data   519 Apr 27 17:55 config-db.php                                      
-rw-r--r--   1 root root       168 Jun 23  2016 config.footer.inc.php                              
-rw-r--r--   1 root root       168 Jun 23  2016 config.header.inc.php                              
-rw-r--r--   1 root root      6319 Jun 23  2016 config.inc.php                                     
-rw-r-----   1 root www-data     8 Apr 26 19:53 htpasswd.setup                                     
-rw-r--r--   1 root root       646 Apr  7  2017 lighttpd.conf                                      
-rw-r--r--   1 root root       198 Jun 23  2016 phpmyadmin.desktop                                 
-rw-r--r--   1 root root       295 Jun 23  2016 phpmyadmin.service

However, /etc/php/7.1/fpm/pool.d/apps.vhost states the fpm socket owner/group is ispapps. ps output confirms that.

Code:

~# ps -ef | grep fpm
root       690     1  0 06:53 ?        00:00:00 php-fpm: master process (/etc/php/7.1/fpm/php-fpm.conf)
ispapps    744   690  0 06:53 ?        00:00:00 php-fpm: pool apps-{fpm_domain}
ispapps    747   690  0 06:53 ?        00:00:00 php-fpm: pool apps-{fpm_domain}
ispconf+   748   690  0 06:53 ?        00:00:04 php-fpm: pool ispconfig
ispconf+   749   690  0 06:53 ?        00:00:04 php-fpm: pool ispconfig
www-data   750   690  0 06:53 ?        00:00:00 php-fpm: pool www
www-data   751   690  0 06:53 ?        00:00:00 php-fpm: pool www
root     14265  9717  0 10:29 pts/4    00:00:00 grep --color=auto fpm

considering www-data is a member of ispapps, I have changed the group ownerships for the 3 files, and the errors disappeared.

Code:

~# chown root:ispapps /var/lib/phpmyadmin/blowfish_secret.inc.php
~# chown root:ispapps /etc/phpmyadmin/config-db.php             
~# chown root:ispapps /var/lib/phpmyadmin/config.inc.php        

I am not quite sure if this will affect any other area in the system though. Comments welcome.
(Note: this issue is similar to server:8081/webmail fails due wrong permissions; for which the solution was changing group ownership of relavant files to ispapps)

 

I have the same problem