copy wp-config.php: failed to open stream: Permission denied in arq-cron.php on line 1084

[protection]

Hello –

Today I made a modification in wp-config.php. Don’t worry, I know what I’m doing in that file 😉

Autorestore then tried to quarantine that file, and I got the following in my PHP error log:

[28-Jul-2017 20:03:11 UTC] PHP Warning: copy(/xxx/xxxxxxxx/public_html/wp-config.php): failed to open stream: Permission denied in /xxx/xxxxxxxx/public_html/wp-content/plugins/bulletproof-security/includes/arq-cron.php on line 1084

I don’t know if it’s related or not, but I also upgraded from PHP 5.6 to PHP 7 (version 7.0.20 ) today.

Any ideas?

Thanks, Pete

[AITpro Admin]

The AutoRestore code at code line 1084 tried to copy the wp-config.php backup file here:  /wp-content/bps-backup/autorestore/root-files/wp-config.php to your root website folder, but the copy was unsuccessful for one of these reasons:

1. The wp-config.php backup file does not exist here:  /wp-content/bps-backup/autorestore/root-files/wp-config.php
2. The /wp-content/bps-backup/autorestore/root-files/ folder does not exist or has been renamed.
3. The folder permissions are too restrictive for the /bps-backup/ folder.
4. The Owner of the /bps-backup/ folder is not the same Owner as your other WordPress folders.
5. You are using the open_basedir directive and the current allowed directory paths are not configured/set/added correctly.

[protection]

Hello –

1.) The backup file (wp-config.php) exists at /wp-content/bps-backup/autorestore/root-files/wp-config.php.

2.) The /wp-content/bps-backup/autorestore/root-files/ folder exists.

3.) Permissions for the /bps-backup/ folder are 755

4.) The owner of /bps-backup/ is the same as the other WP folders.

5.) open_basedir has ‘no value’ according to phpinfo().

Note: I just made a minor change in wp-config.php to see if it would happen again, and it did. I got the same message, however, the updated file did get quarantined while the backed up wp-config.php was autorestored.

Thank you,

Pete

[AITpro Admin]

So are you saying that AutoRestore is correctly quarantining and autorestoring the wp-config.php file?  The php copy() function will overwrite files by default if they exist.  File permissions of the existing wp-config.php file should not matter since copy() will overwrite the existing wp-config.php file.  What are the current file permissions for the wp-config.php file in your website root folder?  If everything is actually working correctly, but you are still seeing that php error message then maybe there is something wrong with your PHP 7 server build/compile?  When php errors occur that do not make any logical sense then that is a pretty good indicator that the PHP build/compile is probably fubar.

[protection]

Yes, the AutoRestore is correctly quarantining the root wp-config.php file  and autorestoring the/wp-content/bps-backup/autorestore/root-files/wp-config.php file, but I get the PHP warning (“failed to open stream”).

I created a simple php script (as shown below) to test the copy() function on PHP 7, which ran with no problems. There were no PHP errors/warnings. It copied file1.txt as file2.txt:

<?php

copy('file1.txt', 'file2.txt');

?>

I then changed the file permissions of file1.txt from “644” to “600” to see what would happen when running the script again. The file copied over with no problems (or warnings), but the file permissions on file2.txt were changed back to 644. What made me want to test this is that I noticed the file permissions for wp-config.php on my root was 400, but the permissions for /wp-content/bps-backup/autorestore/root-files/wp-config.php was 644. Perhaps this is insignificant, but I figured I’d mention it.

[AITpro Admin]

Yep,  you have confirmed that it is not a file or directory permissions problem and not a PHP copy() function problem.  So that leaves you with a complete mystery problem.  Something is incorrectly logging a php error when everything is actually working fine.  Typically that would indicate a PHP server build/compile/installation problem or some sort of server configuration problem somewhere.  Since everything is actually working correctly you can just ignore the php error since it is not accurate/valid.

[protection]

OK, thanks for the quick responses 🙂

[Author]

Posts