Why does One Click Update fail on localhost using FTP with 777 permissions on site files?

Question

I can successfully upload/remove media, add/remove plugins and edit theme files within admin CP. The one thing I can not do in admin CP is a normal one click update from WordPress 3.7.1 to 3.8. Ideas?

The error message when I try to run updates:

Downloading update from https://wordpress.org/wordpress-3.8-new-bundled.zip…

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

For testing purposes, I have all directories and files from the parent down set with 777 permissions and user:group ownership set to my web server user www-data.

-rwxrwxrwx 1 www-data www-data every-freakin-file.php

Output of grep www-data /etc/group show my vsftpd user and my main login.

www-data:x:33:ftps,ryan

The site files are located in a sites-enabled user directory outside of /var/www This is installed on a LAMP private localhost with ports.conf configured as follows.

NameVirtualHost *:80 Listen 127.0.0.1:80

# If you add NameVirtualHost *:443 here, you will also have to change
# the VirtualHost statement in /etc/apache2/sites-available/default-ssl
# to
# Server Name Indication for SSL named virtual hosts is currently not
# supported by MSIE on Windows XP.
Listen 443

Listen 443

Final thoughts: Is there another user that must be added to the www-data group? Does having 777 permissions on every file and directory rule out permissions as the reason for update failure?

I see one solved thread with a selected answer about a "vsftp" config file, but it's too vague to be useful. My /etc/vsftpd.conf configuration is working great except of when I try one click updates.
WP upgrade can't create directory even though perms are 777

Update: My phpinfo.php shows APACHE_RUN_USER and APACHE_RUN_GROUP is www-data. I have confirmed that this user:group owns all files with read/write/execute permissions.

Answer 1

This issue is solved. The permission problem has to do with how files are uploaded to the WordPress site while updating. The suPHP solution is my preference at this point because it is simpler and requires less permissions on files, but if you don't want to do that then you'll have to take care to get your FTP user playing nicely with WordPress.

suPHP Solution
Since posting this question, I have migrated to suPHP which makes it possible for the webserver to run as a local user instead of using the FTP user. Once suPHP was configured (See: Install suphp with apache on ubuntu) I disabled the WordPress Upgrade Constants in wp-config so it was no longer using FTP.

Now one click updating works because the update files are handled by the local user instead of the group that the FTP user belongs to. This means that file permissions of 644 and directory permissions of 755 should work because group write access is no longer needed.

Answer 2

I'm running Apache on OSX and this fixed it for me:

sudo chown -R _www:_www mywebfolder
sudo chmod -R 775 mywebfolder

Answer 3

Error:

The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.

Solution:

1. Check SELinux, make sure it is disabled, and if not, you should disable it. In Putty, #sestatus, the output must be disabled, and if not, edit it at: /etc/selinux/config

2. Change /var/www/html to 777. In Putty: # chmod -R 777 /var/www/html

Other notes:

1. If your web server doesn't enable SELinux, then in most cases, the error will be resolved.

2. This error has nothing to do with file or folder ownership, or group ownership. You can access to ftp serer via WordPress dashboard with root or any other username you created before.

3. I spent 3 days trying to fix this issue, with no success from any Google suggestions. Luckily I have two hosted websites, and one is SELinux disabled, and no one-click update issue, another SELinux enabled website has the one-click update issue, so finally I guessed this may be the issue, and it is true the root cause.