Akeeba Backup for Joomla!

#8530 Pitfalls of open_basedir on a shared server

Posted in ‘Akeeba Backup for Joomla!’
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

Joomla! version
PHP version
Akeeba Backup version

A shared hosting server I use suffered a break-in which defaced many sites. As a result the admin made some modifications in settings in the aid of upgrading security on the server. Among these he activated open_basedir in PHP. This caused some problems with Akeeba and can possibly affect many other components. Following are my observations, my understandings (not necessarily accurate) and the workarounds I implemented.

The first indication I noticed was the failure of a Command Line BU of Akeeba run from Cron. The error was detailed in the email that Cron sends and part of it follows:
Warning: include_once(): open_basedir restriction in effect. File(/home/myUser/domains/myDomain/public_html/administrator/components/com_akeeba/version.php) is not within the allowed path(s): (/var/www/html/:/tmp/) in /home/myUser/domains/myDomain/public_html/administrator/components/com_akeeba/backup.php on line 41

I checked the PHP settings shown in Joomla! Help->System Info and found that the open_basedir value was
which included the base of my hosting package whereas the open-basedir setting shown in the Cron error,
, did not!

My first workaround was to stop using the Command Line Backup option and instead set Cron to run Front End Backkups using curl. At the same time I bounced the open_base dir issue off the hosting support team but did not get very far. They do not allow users to set their own php.ini files but they do have a user specific php.ini files. The existence and location of this user specific file can be found again in Joomla! help->system info->php information as shown:
Loaded Configuration File 	              /usr/local/etc/php5/cgi/php.ini
Scan this dir for additional .ini files 	/usr/local/directadmin/data/users/myUser/php/
additional .ini files parsed 	               /usr/local/directadmin/data/users/myUser/php/php.ini

OK - my understanding is that in the case of my particular hosting, when php is run via appache the two php.ini configuration files that are parsed are the general server one in /usr/local/etc... and a specific file for my hosting. The open-base dir value
is a result of both files being parsed.

As far as the Command Line Back Up - It appears that when the php processor is run from the command line it is not using my user specific .ini file. I tried pointing the Cron run to the user specific file by using the -c option in the command line and the backup ran with no ERRORS. The command was:
/usr/local/bin/php -c   /usr/local/directadmin/data/users/myUser/php/php.ini   /home/myUser/domains/myDomain/public_html/administrator/components/com_akeeba/backup.php -profile 1 -description "db-only"

However the Cron report showed a few WARNINGS. These follow:
Warning: curl_setopt(): CURLOPT_FOLLOWLOCATION cannot be activated when in safe_mode or an open_basedir is set in /home/myUser/domains/myDomain/public_html/administrator/components/com_akeeba/akeeba/plugins/utils/cloudfiles.php on line 213

There were several of these warning as well as one for CURLPROTO_FILE. The backup completed included post processing (to RackCloud).

I tried one more workaround. This time I used the -n option on the php run which ignores all php.ini configuration files
/usr/local/bin/php -n /home/myUser/domains/ -profile 1 -description "db-only"

The result was a perfect backup run - no errors and no warnings. In effect I had cancelled the open_basedir restrictions (default setting is off). This doesn't say much for server security but it worked. Alternately it is possible to create your own php.ini file inside the hosting area and point to it with the -c option.

I hope that this helps someone with open_basedir blues.

Akeeba Staff
You were very close! PHP can actually can have three distinct system-wide configuration files:
1. For mod_php, used by Apache if the PHP is loaded as an Apache module
2. For the CGI binary, which can be loaded either in the command line or by Apache if PHP is loaded in CGI or FastCGI mode
3. For the CLI binary used for command-line backups (backup.php and altbackup.php)

To add to this confusion, some of the global settings can be overridden in the Apache VHOST configuration, per site. The open_basedir is one of them. However, this setting is only applied in the context of web-based calls (i.e. for requests processed through Apache and mod_php or PHP's CGI interface). Since the command-line backup scripts run outside the context of the web server, the per-site settings are not loaded and the global defaults are applied.

In this case, there are only three ways to automate your backups:
1. Disable open_basedir, which compromises your server's security and is not recommended
2. Having a private PHP CLI binary with a private php.ini which has the correct open_basedir permissions (usually impossible on shared hosts)
3. The simplest and safest method: use the front-end backup mode as described in the Automating your backup section of our documentation.

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: 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!

Summer vacations: Our support will be closed for replies and new tickets from August 6th to August 21st, 2022 due to summer vacations.