Yep you read it right. One of our favourite control panels, with one of our least favourite backup systems, are incompatible with Drupal’s strict permissions. The most troubling file is settings.php, which the Drupal installation sets as 555. WHM’s backup simply can’t delete the file because of permissions denied errors meaning you have daily log file to monitor. That’s 365 days a year.
TL;DR
Change all sites/default/ permissions backup from 555 to 755 to incremental backups working. Deal with the security risk at some other time or write WHM a love letter.
Some background
WHM/cPanel probably has one of the worst incremental backup systems available. Sure, the technology of rsync is fine. However, as no compression is available you end up with enormous backups – increasing the cost of shared hosting with around 66% (if you like doing backups). What compounds this shitty situation is that they constantly blare out Jetbackup advertisements in your face making you further loose trust in their own offering (as a side note, Virtualmin has incredible yet simple incremental backups).
The problem is if you have Drupal sites on your server. Pretty soon, after your first truncation cycle, you will end up with daily backup failures and a ton of errors like this:
Subject: [servername] ⛔ Backup transport errors. Transport errors encountered. The system encountered errors during transport of the backup files. Below is a preview of the attached log file. Preview of transport errors log: Unable to prune transport “Incremental Destination Name” Error pruning “backup/server-name/2020-12-15” from “Incremental Destination Name”: child exited with code 1 : Command output => 'rm: cannot remove 'backup/server-name/2020-12-15/accounts/drupal-site-name/homedir/public_html/sites/default/default.settings.php': Permission denied rm: cannot remove 'backup/server-name/2020-12-15/accounts/drupal-site-name/homedir/public_html/sites/default/default.services.yml': Permission denied rm: cannot remove 'backup/server-name/2020-12-15/accounts/drupal-site-name/homedir/public_html/sites/default/files': Permission denied rm: cannot remove 'backup/server-name/2020-12-15/accounts/drupal-site-name/homedir/public_html/sites/default/settings.php': Permission denied' The system could not prune the “backup/server-name/2020-12-15” directory due to an error. Read the go.cpanel.net/directorypruning documentation for solutions to successfully prune the directory. Error pruning “backup/server-name/2020-12-16” from “Incremental Destination Name”: ssh slave failed: timed out The system could not prune the “backup/server-name/2020-12-16” directory due to an error. Read the go.cpanel.net/directorypruning documentation for solutions to successfully prune the directory. This notice is the result of a request from “cpbackup”.
Take a note of the last error:
“ssh slave failed: timed out”
This is bullshit, it’s not a timeout but rather a permissions problem as described further up.
Their reference to prune documentation that’s pretty useless as the timeouts mentioned has nothing to do with the actual problem. Funnily there is a “Permission denied error” section, with nonsense advice:
Permission denied error
The transport may produce an error if the following conditions exist on the server:
A non-root user authenticates to an rsync backup destination.
Files that the user does not possess write privileges to resides in a cPanel user’s directory.
We recommend that you manually delete the files that the system could not remove from the remote destination’s backup.
What? Only root users can do backup? Huh? Do daily cleanups? Did someone say security risk??
Leave a comment if you’re dealing with this same crap.
References
- Daily messages of frustration across many servers
- https://www.drupal.org/docs/7/install/step-3-create-settingsphp-and-the-files-directory
- https://documentation.cpanel.net/display/CKB/How+to+Troubleshoot+a+Remote+Transport+Pruning+Failure#HowtoTroubleshootaRemoteTransportPruningFailure-Permissiondeniederror
1 thought on “Strict Drupal permissions are incompatible with WHM/cPanel incremental backups and causes timeout errors referring to pruning documentation”
Very interesting, thanks. You are the only one post that help me to figure it out why the Drupal files was not deleted by cPanel Backups. Please, keep this info online^^