P15-D24 Posted September 22, 2020 Share Posted September 22, 2020 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 Link to comment Share on other sites More sharing options...
Makoto Posted September 22, 2020 Share Posted September 22, 2020 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) Link to comment Share on other sites More sharing options...
P15-D24 Posted September 22, 2020 Author Share Posted September 22, 2020 Thanks for the quick response. I'll check with my ISP. Link to comment Share on other sites More sharing options...
P15-D24 Posted September 22, 2020 Author Share Posted September 22, 2020 Confirmed the .tar file is getting downloaded to /tmp with a "nobody" owner. (the site default for Apache). Link to comment Share on other sites More sharing options...
Makoto Posted September 22, 2020 Share Posted September 22, 2020 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. SJ77 1 Link to comment Share on other sites More sharing options...
P15-D24 Posted September 22, 2020 Author Share Posted September 22, 2020 (edited) 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 Link to comment Share on other sites More sharing options...
Makoto Posted September 22, 2020 Share Posted September 22, 2020 (edited) 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 Link to comment Share on other sites More sharing options...
P15-D24 Posted September 22, 2020 Author Share Posted September 22, 2020 (edited) /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 Link to comment Share on other sites More sharing options...
Makoto Posted September 22, 2020 Share Posted September 22, 2020 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/ Link to comment Share on other sites More sharing options...
P15-D24 Posted September 22, 2020 Author Share Posted September 22, 2020 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 Link to comment Share on other sites More sharing options...
Makoto Posted September 22, 2020 Share Posted September 22, 2020 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? Link to comment Share on other sites More sharing options...
P15-D24 Posted September 22, 2020 Author Share Posted September 22, 2020 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 Link to comment Share on other sites More sharing options...
P15-D24 Posted September 22, 2020 Author Share Posted September 22, 2020 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. Link to comment Share on other sites More sharing options...
Makoto Posted September 22, 2020 Share Posted September 22, 2020 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. Link to comment Share on other sites More sharing options...
P15-D24 Posted September 23, 2020 Author Share Posted September 23, 2020 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! bfarber and Makoto 2 Link to comment Share on other sites More sharing options...
Makoto Posted September 23, 2020 Share Posted September 23, 2020 Awesome, happy to hear you got it resolved! IP-Gamers 1 Link to comment Share on other sites More sharing options...
Recommended Posts