Support

I have some problems when I try to restore my Admin Tool Pro protected website via Akeeba Backup's own controlpanel. The files upack allright, but I get an error 403 when the restoration script runs. What do I miss?

Best regards

I found that the kickstart restoration script works if I rename the .htaccess file. I suppose it is meant to be like this? Or do I get it wrong?

Best regards

Yes, this is expected. The enhanced .htaccess file created by Admin Tools will block the restore script from executing. Normally the .htaccess is renamed during extraction to prevent this. It is renamed again during the cleanup process to make it live again. For some reason your .htaccess file couldn't be renamed during the extraction. Please take a look at what files you have in the root of your site named .htaccess that do have a file extension. These are not recognized by your web server but may prevent the rename.

Thanks for your reply.

I found a couple of other htaccess files in my root: .htaccess.admintools, .htaccess.old and htaccess.txt. I deleted these, leaving only the normal .htaccess in the root.
I tried to restore from an Akeeba backup file, but (as before) after unpacking the files the script couldn't run (error 403).

So I can't find out what's the best way to use Akeeba Backup and Admin Tools, i e how to restore from Akeeba Backup when Admin Tools is installed on the site.

It seems I am only able to restore my website
- with the Akeeba control panel when no or renamed .htaccess is in the root
- with kickstart when uploading backup copy via ftp and no or renamed .htaccess is in the root

Otherwise I run into error 403.

Best regards

Here's what is happening. Your enhanced .htaccess file contains a rule that the only php file that is allowed to run is Joomla!'s index.php in the root of your site. All other php files have to be called by that one. That's a good thing and that's the way it is supposed to work.

During the restore, we break the rule and you get a 403. That is not unexpected, but that isn't the way it is supposed to work. Kickstart is supposed to rename the .htaccess file during extraction so that when we start the restore, it is already renamed. I can tell the .htaccess file is coming from the backup archive because you can get kickstart.php to run so the .htaccess wasn't there at that point in time (or there is an exemption in your .htaccess file for kickstart.php, possible, but not likely).

Is there an .htaccess file in the root of your site when you start the extraction with kickstart.php? If not, what are the permissions on the .htaccess file that is extracted from your backup archive? If the permissions are something strange like 000 or even 700, that may be why it isn't being renamed.

It's only when I remove or rename the .htaccess file, that the restore script works, etiher from within in the control panel or via kickstart. The script stops if I leave any .htaccsess made by Admin Tools.

The restored .htaccess file is the one created by Admin Tools, it has the permission 644

Best regards

Let's go into .htaccess Maker, in the field "Allow direct access to these files" add

administrator/components/com_akeeba/restore.php
administrator/components/com_joomlaupdate/restore.php

each one on a separate line.

That should help with internal restores, from the Manage Backups screen. I'm not sure about an external restore using Kickstart. I'm not sure what Kickstart calls when it is finished with the extraction and wants to start the restore script.

I am sorry to say, but these lines are already entered into that field. So it doesn't seem to help in my case.

Best rgds

I checked with Davide this morning and those are the correct exceptions for the internal restore (from the Manage Backups screen). Let's go into .htaccess Maker and regenerate the .htaccess file just to make sure they really are in there.

The external restore (with Kickstart) is a different matter. If you're restoring over an existing site, you need to manually delete the existing .htaccess file. The .htaccess that is inside the backup archive should be renamed automatically. If that isn't happening, we need a debug dump of the restore process. To do that, edit kiskstart.php and find the line:

//define('KSDEBUG', 1);

about line 39. Delete the two leading slashes at the beginning of the line ("//"). Then execute kickstart.php again. This should produce a text file in the root of your site. Please zip and post that here and we'll see what is going on with that.

In my htaccess maker I have the lines in place.

And it looks like this in .htaccess:

RewriteRule ^administrator\/components\/com_akeeba\/restore\.php$ - [L]
RewriteRule ^administrator\/components\/com_joomlaupdate\/restore\.php$ - [L]

But it's no big deal. It's OK if I know that I have to remove .htaccess just before running the restore script from within the Akeeba CP.

Best regards :)

That will work.

This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.