AutoRestore File Backup not working – Unable to backup files, DSO, Apache Module, Ownership

[AITpro Admin]

Email Question:
Having an odd issue with one site trying to get BPS set up, so far the others have been a piece of cake! When trying to backup the ARQ Infinity settings files, nothing gets backed up… Any reason of that?

Answer:
I need some more details of exactly what problem is occurring to be able to diagnose the problem or you can send an email to info[at]ait-pro[dot]com requesting that we login and find out what the issue/problem is and fix it.  If you would like for us to login and fix the problem then please create a temporary WordPress Admin login account and send that login information to us.  Thank you.

[AITpro Admin]

Cause of issue/problem:
This issue/problem was unusual and complex and not a typical or common issue/problem.  The website owner recently switched from DSO to suPHP and folder/file Ownership permissions needed to be changed.

Symptoms/Clues:
The /wp-content folder permissions were set to 777

Unable to backup htaccess files to the /bps-backup folder – Error:  “The BPS Backup folder htaccess file – /home/xxxxx/public_html/wp-content/bps-backup/master-backups/.htaccess does not exist.”

Unable to manually activate Deny All BulletProof Mode – Error: “Failed to Activate BulletProof Security Deny All Folder Protection! Your BPS /wp-content/bps-backup folder is NOT Protected with Deny All htaccess folder protection!”

Unable to backup files in AutoRestore to the /bps-backup folder using the AutoRestore Backup Files buttons.

Resolution:
Changed ownership to user:user rather than user:nobody for the /bps-backup folder.

FYI:
If you are not comfortable with doing something like this manually then there is a custom script that will do this for you automatically here >>> http://boomshadow.net/tech/fixes/fixperms-script/

IMPORTANT NOTE:  This script is specifically designed for websites that have cPanel.  If you do not have cPanel then DO NOT use this script.

[AITpro Admin]

Email Question:
I have now installed Bullet Proof on two sites (one a test site, the other live, so similar and same server).

Setup has failed. On ARQ page a backup  is required before ARQ can be turned on invariably fails. However many times I hit the backup button, the red message, File Backup Required Total Backup Files: 1 

The other backups failed a few times but in the end turned blue. But backup of root files never does. Sometimes the Total Backup Files total is 0, sometimes 1. If there is on file it is auto.htaccess.

PHP is running as apache module. But even setting the entire site recursively to 777, the ARQ backup still fails, which stops me turning on ARQ Cron. Please advise.

John

[AITpro Admin]

What is strange to me is that the other backups for the other folders worked at all.  Logically this should be an “all or nothing” thing. For example if the /bps-backup folder has nobody:nobody for [user]:[group] then technically you would not have the rights/permissions to do any backups at all to the /bps-backup folder.  You will need to change the user and group to whatever your user account is.  Example:  myUserAccountName:myUserAccountName for the /bps-backup folder and all subfolders within/under the /bps-backup folder.

This is an excellent free tool/app – WinSCP – that allows you to see and change the ownership permissions for folders and files.

WinSCP is a really nice and easy application for SSH file uploading or changing folder and file ownership. 
You can download WinSCP here >>> http://winscp.net/eng/download.php#download2 – click on either the Portable executables link or the Installation package link to install WinSCP.

[John_B]

I do not get why it does not work when the entire site is 777.
I will try this when I can on my test site as I have a myUserAccount. (I can only work on this server at specified times when my client gives me access).
As said I have two sites in question on same server. On my live site setting backup folder to myUserAccount may not work because I took over a server with document root owner and group being apache:apache (‘apache’ being the user who owns Apache process) and where the parent directory of document root  has owner and group root:root. AFAIK there is no compelling reason why a website document root on a linux server should have a myUserAccount at all, even though this is normal practice, and in this case there is no myUserAccount that I can see (aside from Apache and root).
Can I do a manual backup of the necessary files using cp to get the thing working? I bought the paid version because I was not willing to spend hours debugging myself and I feel cannot pass on the costs of debugging to my client. But I do not mind spending a little time on manual workarounds.

[AITpro Admin]

Linux file permissions and ownership permissions are 2 different things.  Please see this link that explains this very well >>> http://www.ibm.com/developerworks/linux/library/l-lpic1-v3-104-5/index.html

I was using “myUserAccount” as a descriptive example and not a literal example.  This is a ficticious account name and not an official user account name that I used just as an example.

Yes, you could do a manual backup, but I doubt seriously that AutoRestore will work correctly for the Root folder files, but will work correctly for the other folders – wp-content, wp-admin and wp-includes.  AutoRestore needs to be able to access the folders under the /bps-backup folder to compare backed up files with actual website files for any changes to actual website files.  If a change is detected then the backup file would be copied from the bps-backup folder and overwrite the actual website file.  If there is an issue with file ownership here then I do not believe that file autorestore will actually occurr successfully.

I just thought of another cause of this problem – is open_basedir being used in the php.ini file on these websites?  If so, is the Root directory path included in the open_basedir paths?

Also if you do decide to do a manual backup and copy files to the /bps-backup/autorestore/root-files folder this will make the FailSafe Shutdown alert go away.  FailSafes are compartmentalized by Root, wp-content, wp-admin and wp-includes folders so that if there is a problem with one of these folders then AutoRestore will still function correctly for the other folders.

[John_B]

I was aware that myUserAccount is generic. One of the problem websites has owner:group  apache:apache. It follows that the user who owns the website directory in this case is apache. The same user owns the BulletProof backup directory. This should work. In the interests of science if installed the plugin on a different site on a different DSO server, also with the entire site owned by apache-owner:apache-owner and it worked (though I always have to hit the backup button twice).
Possibly my problem site has too many extraneous files in root directory and the backup is timing out. I will have another go at it.
On the server where the backup fails, it returns a page with the blue buttons at the bottom missing. 
Open basedir according phpinfo is ‘no value’ and presumably defaults to off, so no it is not in use. phpinfo also does show that document root is in the open_basedir filepath.
The apache log has no relevant error message.

[AITpro Admin]

Ok I was checking just in case on the “myUserAccount” usage, plus if someone else sees this post then I was making it clear that that was just an example account name.

Are all of these websites on the same Host and same Server?

Hmm since you need to hit the backup button twice on this other site then yes the most logical conclusions would be that you have either run out of memory/resources during the copy/backup or the time limit ran out to complete processing, which I doubt because this is set to unlimited, but most Host’s will force/impose a time limit of 280-300 seconds / 5 minutes.

On the site where it is failing and the page is “breaking/chopped off” this typically indicates that a function is forcibly disallowed or terminated because of some condition/rule on the Server.  The backup function is using the PHP DirectoryIterator Class and this should be allowed on all Servers so I do not think this could be the problem or is being forcibly terminated, but I guess it could be possible.  No one else has had this issue/problem occur and BPS Pro is installed on 100’s of different web hosts.

I have tested copying multiple files as large as 400MB and quantities as large as 6,000 files copied at one time.  This does cause a huge strain on resources and takes a long time, but these copies/backups do complete successfully.  How many files roughly are in the Root directory for this site?  Are there extremely large files?

To confirm that open_basedir is not in use check the B-Core System Info page under PHP Server / PHP.ini Info.  You should see this:  PHP open_basedir: not in use.

Also please double check that the /bps-backup/autorestore/root-files folder has 777 permissions.

[John_B]

Open basedir line on problem site is
PHP open_basedir: /path/to/document/root/:/tmp/
Separate issue:  on the other server where I installed purely for testing and the set up worked, I still have a separate problem (as on the first server) of messages about error log paths being incorrect or different than those seen by server (untrue, although it is true the path is not explicitly set in the server.wide php.ini I prefer to use). This is annoying as everything goes to a central error log. I have spent hours trying to deal with these message, I cannot hand sites to clients with these bold red error messages.  Can I just turn off the php error log messages? I did try following instructions… 
I had no idea installing this plugin would cost so many hours. Still if it keeps hackers out it is worth it.

[AITpro Admin]

Ok open_basedir is a useless feature/directive that does not really add any significant protection (even Kiddie Scripters can beat open_basedir – it is a joke) and typically only causes problems.  The default PHP setting is:  The default is to allow all files to be opened.  What I obviously recommend is that you turn this Off or just comment this directive out, but if you would like to still use this directive then you will need to add the real/actual path to the document root folder instead of the placeholder text.  

“As an Apache module, open_basedir paths from parent directories are now automatically inherited.”

Source:  http://php.net/manual/en/ini.core.php#ini.open-basedir

Well yeah DSO is a completely different animal then CGI / suPHP and WordPress in general and overall has problems with DSO Servers as well as numerous plugins.  Your experience is not the typical user experience since 95% of folks have CGI / suPHP configurations.  Sorry about the extra headaches for you.  In my personal and professional opinion DSO is just not worth the trouble for the slight benefits that you get from using DSO.  😉

If you prefer to handle php error logging from a central location in a sitewide php.ini file then yes by all means just turn this off in S-Monitor.  The option that you want to turn off is:  Php.ini File: Has Been Created, Valid and Error Checks and if you do not want PHP Error notifications displayed then turn that option off as well:  PHP Error Log: New Errors in The PHP Error Log.

[AITpro Admin]

New coding was added as of BPS Pro 5.4 that permanently fixes the Root folder open_basedir issue on DSO / Apache Module configured Servers.

[AITpro Admin]

As of BPS Pro 5.4.1 and the addition of the Plugin Firewall it is now completely safe to change file permissions to 777 or ownership permssions as needed.  The Plugin Firewall blocks remote access to the /plugins folder based on IP Address/your IP address.  No one except for you is allowed to access the plugins folder.  Note:  The /plugins/.htaccess file needs to have 777 permissions in order to function correctly and automatically update your IP address.  This .htaccess file is self protecting meaning that no one except for you can view, open or modify the Plugin Firewall .htaccess file.

[Author]

Posts