Support

Akeeba Backup for WordPress

#34450 – Akeeba Backup won't allow me to set a backup directory outside of the default one.

Posted in ‘Akeeba Backup for WordPress’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Saturday, 30 January 2021 12:42 CST
DA_MAN

I use Akeeba backup to backup my WordPress installation and always set my backup folder outside of the root so if anything happens I don't lose my backups. So I set the Output Directory to: [ROOTPARENT]/sitewide-backups. and hit "use" then save and close. Even if I hit apply beforehand every time I exit the Configuration settings it changes back to the default directory at: [DEFAULT_OUTPUT]. And also has the gull to tell me it is set for the default directory right on the user interface.

This has never happened before - it simply won't allow me to select the folder above the site root. Can you please assist me with this as soon as possible?

 

Regards,

Douglas W

 

Please look at the bottom of this page (under Support Policy Summary) for our support policy summary, containing important information regarding our working hours and our support policy. Thank you!

 
 

Custom Fields

WordPress version (in x.y.z format) 5.6
PHP version (in x.y.z format) php-fpm 7.4.14
Akeeba Backup version (x.y.z format) 7.5.1
 
Saturday, 30 January 2021 22:31 CST
DA_MAN

Now I am getting a www.mydomain refused to connect. In place of the non-working browser window. I have tried uninstalling and reinstalling the plugin to no effect except perhaps making it worse now that I cannot even see the browser window show up, let alone work.

 
 
 
Monday, 01 February 2021 00:59 CST
nicholas

You can set an output directory wherever you want as long as your web server is set up in a way which allows PHP to access it and write to it. There are two reasons why this might not be possible:

  1. Ownership and permissions. Depending on your server setup, your FTP/SFTP user and your web server might be running under different system users and groups. If your new output folder has 0755 permissions, the default, it is read-only to system users and groups which are different to the ones it is owned by. A quick test is to temporarily use 0777 permissions. If that works you need to talk to your host about the best way to handle the folder's permissions and ownership so it's writeable by PHP.
  2. open_basedir. See the official PHP documentation. Many hosts, especially low quality and/or WordPress hosts, use this architecturally incorrect approach in their server configuration. If they limit it to the site's web root you can't use an output directory outside of it. You will need to contact your host and explain your use case. If they refuse to change their configuration you'll have to create a backup output directory inside your web root.

Both of these problems are caused by server configuration we have no say to. The only thing we can do is detect when the output directory is unwritable and fall back to the default so that backups can run. An unwritable output directory not only doesn't let the backups run but also results in no log file being output since it would indeed try to use the output directory which is not writeable to begin with. This had always been a source of frustration which is why we automatically override it for the last several years.

Regarding the cannot connect error, this also comes from your server. It's possible that your host has configured the server in such a way that sending a path in the request — necessary to implement a file browser on a completely stateless CMS like WordPress — is prohibited and results in a connection error. Once again, this is something you need to talk to your host about or just enter paths manually, without using the folder browser. We obviously can't implement a folder browser if it doesn't know which folder it's meant to browse and we have no say on your server configuration.



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Friday, 05 February 2021 07:39 CST
DA_MAN

I know these things that you say to be true, my only mistake was not realizing it was occurring on all of the sites hosted on the server and not just this one because they were not exhibiting this behavior for some odd reason. Turns out there was a misconfiguration in the Apache ssl.config file. I am sorry for taking up your valuable time with an issue like this on my end. If I had only known it was really affecting all sites on the server I never would have posted and would have gone looking in the config files. Strangely enough it was not affecting the other sites in the same way... Thanks again for your time and effort.

Warm regards,

Douglas

 
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

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!