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.