Support » Localhost Installs » Unable to Update WordPress

  • Resolved tinsleyjr


    I have WordPress installed on my Centos 7 server and I have not been able to use the automatic “Update Now” method to update my wordpress site. I have always had to use the manual method. Every time I try I get something like:

    Downloading update from…

    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

    I went through and changed my permissions following the guidance here

    Basically, I changed the file permissions to 664 and the directories to 775. I also changed ownership several times:
    1. the user account and group for my WordPress installation
    2. Web Server account and WordPress group
    3. WordPress account and web server group
    4. web server account and web server group
    5. root account and WordPress group
    6. root account and web server group

    On 5 & 6 I receive a different message saying that it could not create a directory.

    In a last ditch effort (I know not best practice and unsafe) I set the permissions to 777 on all files and directories in my site location and I still get the error.

    Any advice would be greatly appreciated as I am at a loss now that the 777 permissions didn’t even work.

Viewing 14 replies - 1 through 14 (of 14 total)
  • 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.

    [ Signature moderated ]

    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.

    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.


    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 4 years, 3 months ago by Clayton James.
    Thread Starter tinsleyjr


    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.

    Thread Starter tinsleyjr


    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 3 years, 10 months ago by toddalancox. Reason: Further clarification
    Thread Starter tinsleyjr


    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:

Viewing 14 replies - 1 through 14 (of 14 total)
  • The topic ‘Unable to Update WordPress’ is closed to new replies.