Site Restoration

#37853 Can't Extract Files Using Kickstart

Posted in ‘Site restoration’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

PHP version
CMS Type
CMS Version
Backup Tool Version
Kickstart version

Latest post by nicholas on Monday, 10 October 2022 01:16 CDT


I am unable to restore a backup of my site. When I run Kickstart.php, I get the opening splash screen, but when I try to run the extraction I get a message that says,

An error occurred

Could not upload installation/README.html

I took a backup of my staging site, which showed a successful backup. I copied the .JPA file off-site, then deleted the files in the webroot folder. I then attempted to restore the site using Kickstart.php. The Kickstart opening screen came up, but when I tried to run the extraction, I received the above message.

The webroot folder, ../html, is set to owner: apache:apache; permissions: 755. The two files are set to owner:apache:apache; permissions 644.

I do not believe this is a corrupt backup, as I am able to extract the files to another server without problems. I'm reasonably sure this isn't a problem with Akeeba or Kickstart, as the file extracts on another server. I suspect that there is a configuration problem with the server I am trying to restore to. I'm hoping you have had experience with the error message and can provide some suggestions as to why I can't extract the files to this server.


Akeeba Staff

This is not a corrupt backup. As you said, you can restore on another host. Moreover, I can see that it does read the very first file added to the backup archive at backup time, it just cannot write it to the disk.

I believe this is a problem with the ownership and permissions of the html folder which needs to be addressed by your host. Remember that your web server runs under a user and group. Whether it can write to disk depends on what this user and group is and what are the ownership and permission settings for the html folder it tries to write into.

On modern servers set up correctly, each site runs under its own user and group. It does not run under the Apache user/group (apache:apache, nouser:nogroup or www-data:www-data are the usual user/group settings used for Apache in the most common Linux distributions used on commercial servers, i.e. RedHat and Debian derivatives including CentOS, Rocky Linux, and Ubuntu Server). If the site —therefore PHP itself— runs under its own user but the html folder is owned by apache:apache with 0755 permissions then the user PHP runs under can only read from that folder, not write to it, hence the error message.

This is already explained in and

However, I do NOT recommend going the FTP route. It's best to ask your host for support.

As to whether I have experience with that: yes, I do :) I have a test server on a commercial IaaS company running Ubuntu Server. NginX (that server does not use Apache) runs as www-data:www-data. However, I create a new PHP-FPM pool for each test site running as its own user and group www-data, e.g. test3:www-data. I have one folder for each hosted site under /var/www e.g. /var/www/test3. This folder has ownership test3:www-data and permissions 0755. This isolates writing from one site to the other (but not reading — I don't care about that since it's a test server).

If I had left each folder with the default ownership of www-data:www-data and permissions 0755 PHP would not be able to write to these folders. I actually did that, by accident, when setting up the server and I of course could not restore backups; I had the same error you see. Changing the ownership of the folders to match each hosted site's PHP-FPM pool's user did the trick.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!