Support

This is a permissions issue, as you correctly understood the first time around. Please ask your host for help.

Most likely, when you upgraded your site FTP was involved and your server does not use PHP-FPM. As a result, the owner user and/or group of the files is such that PHP cannot write to the files directly. Your host will be able to change the ownership and permissions of existing files, making them writeable to PHP.

A very unlikely alternative is that you are out of disk space. However, given that you get an error overwriting a file with something that is if not the exact same size then just a few bytes over (we're talking about a dozen or so bytes...) I don't think that's even worth considering.

As for PHP versions, we develop our software on PHP 8.3 and test with 8.2, 8.1, 8.0, and 7.4. Besides, the PHP version alone would not result in being unable to write files. At worst, a different PHP version might not have the gzip extension enabled which would result in a different error telling you the compressed files cannot be uncompressed. However, this is ABSOLUTELY NOT the case here since you've already extracted the entire installation folder before hitting an unwriteable file, i.e. you are 100% looking at a permissions issue.

Permissions and ownership. They work together to determine who can do what. Please read the Security Information chapter of Akeeba Backup.

Unfortunately, I cannot tell you what is the correct permissions and ownership for your server for two reasons. First, I have not set up this server myself. Second, I have obviously not set up this server myself, as I know how to correctly set up PHP-FPM with Apache to not have to deal with this kind of permissions hell situation ;)

What I can tell you, however, is the "Hail Mary" approach which might actually be most productive in your use case.

Before you do anything else, please make sure you have downloaded all your backup archives locally and kept a second copy of them on an external hard drive / USB key just in case.

Delete all the files and folders from your site's root. Then, upload your backup archive and Kickstart and restore your site.

You're welcome!

My response to that is "What a load of utter nonsense!". Do these halfwitted mouth-breathers not realise who I am? I configure and set up my own servers, and write tutorials about it, for Christ's sake.

Kickstart has been around since 2008. It is what Joomla itself uses in the Joomla! Update component; verbatim from Joomla! 2.5.1 up to and including Joomla! 4.2.1, derivative since 4.2.2. If they cannot figure out it's not "malicious" software, they need to be repeatedly hit with a clue-by-four on the head.

I have sites on Rochen which also uses Immunify360. The script is NOT marked as "malicious" or any such nonsense, presumably because Rochen is a competent host. Apparently, your host is beyond incompetent.

But that's irrelevant, because it's all been a lie.

You have already managed to run Kickstart, therefore their claim that Immunify360 considered it "malicious" is an obvious lie. If it was marked as "malicious" it wouldn't run.

Ownership and permissions of files have sod all to do with any of what they claim, as anyone with two brain cells to rub together knows. If they are running PHP as an Apache module the only thing which determines the user and group PHP runs under is the user and group Apache itself runs under -- either as defined in the /etc/apache2/httpd.conf file, or as defined in the hosting user-specific chroot jail. If they are running PHP through PHP-FPM then it depends entirely on the PHP-FPM pool configuration.

My conclusion is that your host is completely incompetent, they run PHP as an Apache module, they do not understand how to set up cPanel so as not to create a permissions hell (even though this is a simple, and well-known configuration for the past 20 years), and they lie to you to sleaze their way out of doing what you pay them to do. Therefore, I would recommend moving to a different host.

As I mentioned already, I use Rochen without any major problems. Minor problems they fix near instantly upon submitting a ticket. Full disclosure: Rochen provides free hosting for our business site, but I am paying their full rate to host all of my other sites.

I am not angry, I am flabbergasted that these clowns keep lying to you because they don't understand how their own servers work, they are not doing the job they are being paid to do, and have still not figured out that I know a lot more about hosting than they do. It's not my job to fix their piss-poor hosting, but here we are.

In case these dimwits really have no idea how their server works, LiteSpeed uses LSPHP (basically, a proprietary SAPI to PHP which is conceptually somewhere between a server module and a PHP process manager) which does support suEXEC, i.e. it allows each PHP thread to run under the UID and GID of the hosting user account of a specific site. Here's the documentation: https://docs.litespeedtech.com/lsws/extapp/php/configuration/advanced/#suexec Using suEXEC they avoid the permissions hell. This operating mode predates LiteSpeed; it was called suPHP twenty-odd years ago. LiteSpeed simply uses the same trick we were using on Apache back in the earliest days of commercial PHP hosting.

All they had to do is read the f...ing manual and do the job they are paid to do.

Do you need any more proof they are beyond incompetent?

It's up to you. I can already see where this is going.

That's probably the most efficient choice, I agree.