Unable to Update WordPress

Hi,

The automatic updates won’t work with the localhost WordPress setup. You have to do the updates manually if we have the site installed in our local machine irrespective of the operating system.

Regards,
[ Signature moderated ]

• This reply was modified 7 years, 9 months ago by Steven Stern (sterndata).

The automatic updates won’t work with the localhost WordPress setup. You have to do the updates manually if we have the site installed in our local machine irrespective of the operating system.

This is not normally the case. The symptom is usually due to a conflict in httpd/php process ownership/permissions vs user account file ownership/permissions, and can depend a lot on the hosting environment configuration.

Some reference information: Permission Scheme for WordPress

CentOS 7 is a commercial operating system, so this is not likely to be a home/localhost installation. (Though I do agree that WordPress updates work fine in localhost installs as long as Apache is installed correctly.)

To the OP: did you reset the owner/permissions of the main WordPress directory, or only its subdirectoories? If any directory in the WordPress installation has the incorrect permissions/ownership, including the main directory, the update will fail.

Having said this, your problem may be at the system level. Do you have mod_security installed? If so, make sure its rules aren’t blocking the update. Also make sure there are no SELinux policies that are blocking the update; while it’s unlikely SELinux is the issue in this case, it is well known to cause problems similar to this.

A) CentOS 7 is a freely available RHEL based Linux distribution. Anyone can download and use it. https://www.centos.org/download/

B) The only SELinux related issues I’ve encountered on any of my own CentOS installations that could possibly inhibit automatic updates or theme/plugin installations, is the “httpd_can_network_connect” context, which is denied by default.

Reference: https://wiki.centos.org/TipsAndTricks/SelinuxBooleans

In my experience, SELinux is generally enable by default in most CentOS installations.

If that is indeed your issue, then “setsebool -P httpd_can_network_connect on” from a console ( as “su -” ) should solve the problem.

Otherwise, see everything else I mentioned, and carry on. ??

• This reply was modified 7 years, 9 months ago by Clayton James.

I appreciate everyone’s input on this matter.
@claytonjames I tried setting the SE configuration you mentioned, but unfortunately, that did not solve my issue. I have wordpress installed to the root of my html directory (i.e. /var/www/html) and ran these two commands on that directory

> find /var/www/html -type f -exec chmod 664 {} \;
> find /var/www/html -type d -exec chmod 775 {} \;

According to everything I have read, my permissions on my wordpress should be configured correctly.

Furthermore, I verified what httpd is running as and, as of right now, I have the owner:group for the files and directories in /var/www/html configured for the account used by httpd.

The screwy thing is as I mentioned in my first post, when I set the permissions temporarily to 777 I still get the error. I know I’m missing something, I’m just not sure where.

Well…, I ended up finding out what my issue was, I had to temporarily disable SELinux. I still need to figure out how to avoid having to disable SELinux each time I need to update, but running two simple commands over manually updating my site is much easier. If any of you have any insite into why SELinux was my problem, or how to configure SELinux that would be much appreciated. I’ll leave this post up for a little while before I mark it as answered to see if anyone has a response to the SELinux issue.

I’m a bit (but only a bit) surprised that SELinux was the issue. It’s a “feature” that was a great idea, but its implementation was hopelessly complex and overly intrusive. Many hosting providers disable SELinux on CentOS-based VPS and dedicated servers because doing so reduces the number of support tickets submitted by customers.

If you do find the policy which caused your problem, please make sure to let us know which one it was.

I believe I was running into this same problem with CentOs 7. I had recently migrated the site from a Solaris host and this was my first update which failed. I was attempting to update from 4.8.2 to 4.8.3. I eventually tracked down the initial failure to the inability to copy update-core.php during the upgrade process. All permissions were correct.

I finally looked at SELinux as a factor and found that the SELinux context on the files was different:

[root@www includes]# ls -Z /var/www/html/
-rw-rw-r–. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 index.php
-rw-rw-r–. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 license.txt
-rw-rw-r–. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 readme.html
-rw-rw-r–. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-activate.php
drwxrwxr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-admin
-rw-rw-r–. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-blog-header.php
-rw-rw-r–. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-comments-post.php
-rw——-. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-config.php
-rw-rw-r–. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-config-sample.php
drwxrwxr-x. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 wp-content
-rw-rw-r–. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-cron.php
drwxrwxr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-includes

I found that I needed to have the http_sys_rw_content_t context on the other files and directories. I changed the context with:

chcon -R --type httpd_sys_rw_content_t /var/www/html/

After restarting apache I’m now able to update normally through WordPress.

• This reply was modified 7 years, 4 months ago by toddalancox. Reason: Further clarification

Thank you toddalancox. You got me on the right track. I wasn’t able to use the --type option with chconu since, I guess, it wasn’t in my SELinux policy. I kept getting “Invalid Argument” whenever I ran that command. Instead I had to reference my wp-content directory that had the httpd_sys_rw_content_t type. I used this command to get it to work sudo chcon --reference=/var/www/html/wp-content -R /var/www/html/. Thank you all for your help.

Thanks @toddalancox – after 2 years of wrestling with this issue and trying many many solutions, you post resolved it for me! Damn SELinux ??

OMG! what an entrance to your world of linux/fedora/apache/mariadb/wordpress/selinux!
I have just started learning this world with so much enthusiasm 2 weeks ago and I absolutely loving it!
I find my self debugging most of my time but I guess its the best way to learn.
Just wanted to stop by and say THANK YOU so much @toddalancox for the solution. Damn SELinux ??

This is all great information @toddalancox, as it leads to my problem I was having with updating WordPress core from the web UI. It feels kinda of scary apply a sweeping policy to the entire /www/html/ directory.

Would it be safer to apply this on only the webroot eg: /www/html/wordpress? If I’m understanding this correct, all this policy is doing is allowing httpd access to read/write in the directory.

Are there any additional security concerns with applying the SELinux policy to the entire directory?

@mbrost I am unfortunately not an expert with SELinux. I suppose there are always security concerns with anything we do these days.

Still, in any system I have seen, the apache/httpd process had full control over the /www/html or equivalent directory hierarchy. In my case, I don’t have a WordPress directory beneath /www/html.

You could certainly apply the policy to specific directories within WordPress and test to see what the minimum grant needed is.

I spent days trying to determine what besides file permissions was causing the WordPress update to fail on a Google Cloud Centos 7 instance. I never encountered this before.

@toddalancox was correct. The problem I had was in the SELinux security area.

Here is how I fixed my installation:

1. I ran “sestatus”
and got back this:

SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28

2. Then I ran: “sudo setenforce 0” which changes the mode to permissive.
Which then after another status gave me:

SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28

Notice the current mode status changed from enforcing to permissive.

3. I restarted Apache
4. Ran the WordPress update without any problems.
5. I ran “sudo setenforce 1 ” to reset the permissions back to enforcing.

I’m not sure of the security issues if I left it in the permission state. Will do more reading to understand it better. I also not yet tried to permanently leave it as permissive for persistent through a system reboot, edit the ‘SELINUX=’ line in /etc/selinux/config for either ‘enforcing’, ‘permissive’, or ‘disabled’. For example: ‘SELINUX=permissive’

The SELunix link for info is: https://wiki.centos.org/HowTos/SELinux