Table of Contents
- Q001 - The output directory is not writable
- Q002 - The temporary directory is not writable
- Q003 - Using site root as Output directory
- Q004 - PHP memory_limit too low
- Q011 - Missing root definition for backup
- Q012 - Missing database connection information for backup
- Q013 - Using backup software directory as output directory
- Q014 - Cannot create default output directory (Akeeba Backup for WordPress)
- Q015 - Joomla! custom public folder with Dereference Links enabled
- Q101 - open_basedir restrictions effective on the output directory
- Q103 - Maximum execution time is too low
- Q104 - Temp directory is the same as the site's root
- Q105 - Log directory is the same as the site's root
- Q106 - Uppercase letters in table name prefix
- Q201 - Obsolete version of PHP
- Q202 - Unable to reliably calculate CRC
- Q203 - Default output directory in use
- Q204 - Disabled functions may affect operation
- Q401 - ZIP archive format selected
- R101 - The restoration URL contains the path of the original site's URL
When Akeeba Backup and Akeeba Solo detect established or potential problems with respect to your server setup or their own configuration they will raise warnings. These warnings are displayed both in the Control Panel (on the "Status Details" pane) and on the first backup page, where you enter the backup details. Clicking on each of these warnings will bring you to the relevant page of this section of our site. Reading the article will let you understand what our backup software detected as an error, how it will affect your backup experience and – most importantly! – the possible workarounds.
![[Warning]](/media/com_docimport/admonition/warning.png) | Warning |
|---|---|
|
Your backup will not work when this message is displayed! |
The backup output directory is unwritable or no longer exists. Under this circumstances a backup archive cannot be created. Possible reasons are:
-
If you just transferred or restored your site, Akeeba Backup remembers the output directory path of the site that was backed up. In this case, simply go to Akeeba Backup's Configuration page, find the Output Directory field and enter [DEFAULT_OUTPUT] (all caps, include the brackets) and click on Save. This will reset your output directory to the default setting (Joomla!: administrator/components/com_akeeba/backup; WordPress: wp-content/plugins/akeebabackupwp/app/backups; Akeeba Solo standalone: backups – all paths under your site's root). If the directory still appears unwritable, check the items below for possible causes.
-
Wrong directory permissions. Directory permissions are described in detail in our user manual. We advise you to take a look at it. Please note that due to the way backup archives have to be accessed, Akeeba Backup / Akeeba Solo can not make use of FTP mode when writing to backup archives.
-
There are open_basedir restrictions in effect; if this is so, changing permissions won't help. You will have to choose another directory.
-
There is some other host-specific restriction we have not yet encountered. In this case, contact your host.
To fix this issue, make sure your backup output directory has sufficient permissions. If you are unsure, 0777 (read, write and execute/browse permissions for user, group and others) will work, but remember that they are the broadest permissions settings and you might not want this, unless it's absolutely necessary.
![[Tip]](/media/com_docimport/admonition/tip.png) | Tip |
|---|---|
|
If you are on Apache server and your host allows the use of .htaccess files, you can easily protect your backup output directory. Just create a new text file inside it. Name it .htaccess (note the dot before the filename, it's important). Edit this file so that its only contents are: <IfModule !mod_authz_core.c> Order deny,allow Deny from all </IfModule> <IfModule mod_authz_core.c> <RequireAll> Require all denied </RequireAll> </IfModule> |