WordPress update fails with a "permission denied" error?

Question

I have a Wordpress installation that refuses to auto update using the standard update button in the dashboard. The error received is:

"Unpacking the update… The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php….. Installation Failed"

Warning: copy(/var/www/html/wp-admin/includes/update-core.php): failed to open stream: Permission denied in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 281

Information about the site:

• On Google cloud's Compute Engine
• Appropriate public key and firewall entries to allow access for DB, ssh2, etc. from local desktop
• Site runs with Apache, PHP 7.3, MariaDB on a Centos 7 system
• All functions except for the update run fine. This includes all normal pages, posts, etc. and the plugin updates
• All file permissions are set to 664, folder to 775 as recommended by Wordpress
• In the wp-config file there is "define('FS_METHOD','direct');"
• Wordpress user is "apache"
• FTP user is "ftpusername"
• ftpusername belongs to group ftpusername as does apache
• All files and folders are owned by apache
• All files and folder belong to group "apache"

Access to the site is by SFTP Filezilla with user "ftpusername" and private key. SSH is using MobaXterm using the same user and private key

I need to determine what user the Wordpress update process thinks it is since it is not the user that runs all the other pages and posts as I have all files and folders owner by apache.

Answer 1

I need to determine what user the Wordpress update process thinks it is since it is not the user that runs all the other pages and posts as I have all files and folders owner by apache.

The WordPress update process has no idea which user it's running as, nor does it care. It doesn't even check the user, and why should it. The owner of the file and the user the PHP process is running as may differ deliberatly. If it's the wrong user then WP will neither know or be able to do anything about it.

All code ran by PHP-FPM will be running under the same user, regardless of wether it's WordPress or a quick info.php you put in the web root.

Here's your problem:

Warning: copy(/var/www/html/wp-admin/includes/update-core.php): failed to open stream: Permission denied in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 281

Code running from PHP files does not have permission to modify that file. That PHP warning is from PHP itself, it's not something WordPress has output.

You need to:

• confirm that the file is writable/deletable from the PHP process user
• confirm that the folder is writable/deletable from the PHP process user. Just because the file permission is good doesn't mean the folder is good too
• that the ownership of that folder is correct, both for the owning user, and the owning group. Just because the file permission and folder permissions are good, doesn't mean they apply to the PHP process user.

It's not as simple as setting the right permission number with chmod. Ownership matters hugely.

For example, 664:

664 is useless to you if the owner is root. apache is neither the root user or in the root group ( I'm assuming that's the case on your specific system ).

As a result, apache would fall into the other bucket, and other groups only have read access.

However, if it was owned by another user that shared the same group as apache, or if it was owned by apache itself, then 664 might work as it'd be owner or group rights that apply.

What about 775?

It's the same but you've made the files executable.

So there is no WordPress specific solution here to your problem, which is that the folders aren't writable by PHP scripts.

---

As an aside, you should be making all your WP Core files read only to the PHP user so malware can't modify them, then using an external tool to update WP, such as WP CLI on a cron job, or version control such as git.

Eitherway your problem and solution involves file/folder ownership and permissions. Perhaps your apache user isn't in the appropriate group. Maybe it doesn't own the files? Only you can tell.