Can't install 3rd party upgrades at all, server config error

[P15-D24]

Need an installation debug guru!!

Upgraded to 4.5.2, set up the Marketplace and tried upgrading out of date apps.  They error out with basically the same message: Extraction from phar "/tmp/IPSMP9XoNAU.tar" failed: Cannot extract "Application.php" to "/usr/home/*****/public_html/*****_forum/applications/classifieds/Application.php", setting file permissions failed

I've reset the file privs to 777 in the classifieds dir for testing, same error. 

The classified publisher says it's an IPS error, IPS says it's a ISP error. ISP need more info as what is wrong. And I'm dead in the water. 

In looking at the previous line in the error file: #0 /usr/home/****/public_html/*****_forum/applications/core/modules/admin/marketplace/marketplace.php(842): PharData->extractTo() it looks like it starts to extract the tar file but then can't set the privy on the target file or directory.  I'm wondering if some specific PHP function needs to be enabled to allow the privs change.  I ran the IPS PHP config checker and everything was set correctly.  Again this error occurs for any updates I try to run out of marketplace. 

Any suggestions how to debug the issue would be greatly appreciated. 

TIA 

 

[Makoto]

Are you using ACL permissions on your hosting server by chance?

PHP's PHAR library does not work properly with ACL permissions if so.

Try chowning all files in applications so that they are owned by whatever user PHP/Apache is running as (e.g. www-data)

[P15-D24]

Thanks for the quick response. I'll check with my ISP.

[P15-D24]

Confirmed the .tar file is getting downloaded to /tmp with a "nobody" owner. (the site default for Apache). 

[Makoto]

2 hours ago, P15-D24 said:

Confirmed the .tar file is getting downloaded to /tmp with a "nobody" owner. (the site default for Apache). 

What is the output when you run the namei -nom command on your web root?

e.g.

namei -nom /usr/home/*****/public_html/*****_forum

You can redact the sensitive bits, just need to verify the permissions.

[P15-D24]

drwxr-xr-x root  wheel /

drwxr-xr-x root  wheel usr

drwxr-xr-x root  wheel home

drwx---r-x v users m********r

drwx---r-x m********r users public_html

drwxr-xr-x m********r users *********_forum

Edited September 22, 2020 by P15-D24

[Makoto]

3 hours ago, P15-D24 said:

drwxr-xr-x root  wheel /

drwxr-xr-x root  wheel usr

drwxr-xr-x root  wheel home

drwx---r-x v users m********r

drwx---r-x m********r users public_html

drwxr-xr-x m********r users *********_forum

Just to verify a bit further, can you run the same command on /usr/home/*****/public_html/*****_forum/applications/classifieds/Application.php

Additionally, please paste the output when you run the getfattr command on this file, as well as the classifieds directory itself.

Edited September 22, 2020 by Makoto

[P15-D24]

/usr/home/*****/public_html/*****_forum/applications/classifieds/Application.php

 

drwxr-xr-x root  wheel /

drwxr-xr-x root  wheel usr

drwxr-xr-x root  wheel home

drwx---r-x m*****r users m*****r

drwx---r-x m*****r users public_html

drwxr-xr-x m*****r users ********_forum

drwxrwxrwx m*****r users applications

drwxr-xr-x m*****r users classifieds

-rw-rw-rw- m*****r users Application.php

Right now I don't have getfattr installed on my site. (Ubuntu install)  Checking with the ISP now. 

 

Edited September 22, 2020 by P15-D24

[Makoto]

Looks like the classifieds directory is missing global write permissions. You don't need to worry about getfattr, just run this to update your permissions and you should be good:

chmod -R a+rwX /usr/home/*****/public_html/*****_forum/applications/

[P15-D24]

Did the chmod, still get the same error. 

Extraction from phar "/tmp/IPSMPMYPm5N.tar" failed: Cannot extract "Application.php" to "/usr/home/m*****r/public_html/*******_forum/applications/classifieds/Application.php", setting file permissions failed

[Makoto]

Can you run the namei -nom command on Applications.php again to verify the permissions were changed accordingly?

Do you have SELinux enabled on this box, and do you know what /usr/home is mounted as? Is it a local filesystem, or a network mount?

Lastly, you haven't changed the IPS_FOLDER_PERMISSION setting in constants.php or anything have you?

[P15-D24]

drwxr-xr-x root  wheel /

drwxr-xr-x root  wheel usr

drwxr-xr-x root  wheel home

drwx---r-x m*****r users m*****r

drwx---r-x m*****r users public_html

drwxr-xr-x m*****r users ********_forum

drwxrwxrwx m*****r users applications

drwxrwxrwx m*****r users classifieds

-rw-rw-rw- m*****r users Application.php

The site is a dedicated Ubuntu VM, I'm the only user.  SELinux is not used. 

Haven't touched constants.php

[P15-D24]

Another data point. My ISP support team pinged why all the questions and what was going on. I sent them the error message and their response: 

"This is due to the servers default configuration. The server by default will run all PHP scripts under its own username of "nobody" instead of your accounts username. When this happens all created files inherit those permissions. This can create permissions conflicts where files cannot be modified as they are not owned by your username. To prevent this you can configure the script wrapper SuEXEC. This will cause the apache server to run all PHP scripts under your accounts username. This will prevent any such permissions conflicts from happening in the future."

I don't know if you have seen this issue in the past or have additional ideas for a work around. 

About a year ago this issue appeared when doing another update and I tried SuExec and it was a total disaster. Took my production site down for 3 days while doing a restore from backup of everything and nobody could figure out what caused the issues.   

 

[Makoto]

It shouldn't matter considering the files and directory have public write permissions set, unless SELinux or some form of extended attributes are being used.

If you want to send me a PM I could take a closer look at this myself but otherwise I can't think of anything else that would cause this issue off the top of my head right now.

[P15-D24]

Mystery solved, my ISP support team just sent this to me:

"The older PHP configuration that your server was using may be to blame. To test this theory, we converted your server to use FCGI instead of mod_php. This newer server configuration will solve the user "nobody" problem, without going through the SuEXEC steps. Please note that .htaccess PHP settings will not work anymore. You will need to use a .user.ini file instead to change PHP directives. Please try to run your installation again and let us know how it goes."

Ran the updater worked perfectly first time.

Thank you for all the help, very much appreciated! 

[Makoto]

Awesome, happy to hear you got it resolved!