Support

On my linux servers, the kickstart based installation proceeds normally but the home page says “The requested page can’t be found.” “404 page not found”. 

That's a .htaccess issue. Use the option in the restoration's Site Setup page to replace the .htaccess file with the default. See https://www.akeeba.com/documentation/akeeba-backup-joomla/angie-joomla-setup.html 

Make sure that you have mod_rewrite enabled in your web server (Apache); it is necessary for SEF URLs to work. See https://www.akeeba.com/documentation/akeeba-backup-joomla/restoration-troubleshooting.html#prbasicts 

If you are using any third party plugins which may be doing redirections, SEF, or something similar they might need to be adjusted. See https://www.akeeba.com/documentation/akeeba-backup-joomla/restoration-troubleshooting.html#prbasicts 

Finally, do note that as per the documentation if you restore to a temporary URL (the one that has something like /~something in it) your site won't work. This is a limitation of Apache. See https://www.akeeba.com/documentation/akeeba-backup-joomla/backup-now.html 

The administrator page comes up with the password section which fails.

Use the option in the restoration's Site Setup page to remove the .htaccess and .htpasswd files from the administrator folder. See https://www.akeeba.com/documentation/akeeba-backup-joomla/angie-joomla-setup.html 

Kickstart immediately gives an error indicating the “Readme.html” file can’t be written to regardless of what level of permission I’ve provided to the domain or the files within the domain including the installation folder and the Readme.html file.

It's a permissions and ownership issue. Please read the Security Information section of the documentation very carefully. See https://www.akeeba.com/documentation/akeeba-backup-joomla/security-info.html 

After reading that, you will understand that the problem is that your site's root is not writeable to PHP because it is owned by a different user than the one your web server and PHP runs under. You have to ask your host to fix that problem, or use the FTP method to upload the extracted files. See https://www.akeeba.com/documentation/akeeba-kickstart-documentation/kscantextract.html and https://www.akeeba.com/documentation/akeeba-kickstart-documentation/kstslive.html However, using the FTP method will result in a non-functional site as Joomla! itself cannot write to its own files, something which is necessary for Joomla! 4.0 and later. Do note that Joomla 4 has removed the FTP layer as having a server where PHP cannot write to files is inexcusable nowadays.

Ultimately, it is a server configuration issue. It is 2023. There is absolutely no reason to have a server configuration where the web server and PHP run under a different user than the hosting account's user. The solution to this problem is known for the past FIFTEEN (15) YEARS. If your host has not figured out a fundamental aspect of hosting PHP that is widely known for the past 15 years I would posit they do not actually understand how to host PHP sites and should not be trusted. In fact, this kind of host cannot be used with Joomla! 4.0 and later.

 Sites come up OK but Home Dashboard on backends show unknown Joomla, unknown extensions, error on overrides and unknown requests and help.

This actually has nothing to do with the backup. It is an issue I reported to Joomla nearly two years ago and they decided not to fix it.

The problem cause is really simple: Joomla is making too many AJAX requests in too little time. This is a problem I first say 17 years ago in the first versions of JoomlaPack (that's what Akeeba Backup was called back then). That's why Akeeba Backup has the Minimum Execution Time, Maximum Execution Time, and Execution Time Bias settings under Fine Tuning ever since.

What actually happens is that your web server has a module (probably the – defunct since 2017 – mod_evasive) which "sees" a large number of similar-looking requests coming from the same IP address in a sort period of time and thereby blocks all requests from that IP address for a while (usually a few seconds).

The solution to that is two-fold. First, not make all AJAX requests (Joomla 4 makes nearly a dozen of them in the control panel page!) at the same time. Rather, make them sequentially. This is part of the fix I submitted almost two years ago and was accepted and added to Joomla.

The second part is adding a delay between requests and apply an exponential back-off strategy before retrying them. This part was rejected on principle by the Joomla! maintainers, so I never wrote or contributed such code. This is why you still have this problem.

However, two years later, I can say that this is more of a problem on your server than it is with Joomla! itself.

Remember when I casually mentioned that mod_evasive is defunct since 2017? There is a reason for that. 17 years ago the web was a different place. AJAX (Asynchronous JavaScript And XML) was a brand new thing with emerging support from browsers of that era. There was almost nobody doing lots of requests close to one another. Moreover, servers had limited memory, disk I/O capacity (a spinning platter 7200 RPM drive on Serially Attached SCSI, a.k.a. SAS, was quite the top-end hardware at the time!), and network bandwidth. Every request took seconds to process. So, seeing something doing a bunch of requests to a .php file within five seconds was almost certainly an indication of a hack.

Fast forward to 2023. AJAX / Fetch is common practice and widely implemented. There are hundreds of JS frameworks which require it to even do anything useful. Servers are blazing fast. Dynamic pages (server side scripts) respond within a few hundred milliseconds or less. Having plenty of requests per second is no longer a sign of being attacked; it's just an ordinary day. So, by 2017 having something like mod_evasive no longer made any sense and it was discontinued. Unfortunately, some server engineers never got the memo, or kept migrating servers from configurations which had installed it well over a decade ago.

You need to tell your host to disable any such protection module on the web server. These no longer make sense.

If you are worried about attacks, use CloudFlare or Sucuri. They do a far better job at detecting real attacks than any of the web server modules ever could.