The update could not be unpacked, Installation Failed

I’m not using the WordFence plugin, so I don’t think its that. Disabling the plugins before running the update will eliminate any potential plugin problems.

Something I did notice is that the issue only appeared on sites I manage that use CloudFlare.

Are any of you using CloudFlare?

I use Wordfence on the affected sites, but not Cloudflare.

I tried disabling Wordfence, but that made no difference.

I run VSFTPD on Jessie, thats why I need FTP to update, so the necessary ftp access information is in wp-config.php.

I noticed that the WP upgrade file is downloaded, extracted and then deleted again (I see the deletion commands in the FTP log) – so it does not seem like extraction is not working.

Owner of webserver created files is www-data – owner of ftp created files is the virtual server owner (username = domainname)

I have noticed that the WP core update works when I do

chmod -R www-data /home/mydomain.com/public_html

run the update (works fine), then

chmod -R mydomain.com /home/mydomain.com/public_html

to get the original permissions again

So as far as I can see it must be some permission problem when using FTP ext instead of direct access, and this was introduced in 4.5 or the version before 4.5

Additional information: I use Virtualmin to manage the server.

That’s my input for now…

I dont use Wordfence or CloudFlare. I have a dedicated server from OVH. I have always used the OVH Debian-Jessie-ispconfig. I have never had any upgrading problems in the past. I am using the same setup for the last 5 years! o_0

Very interesting.

netsolution, I presume you meant “chown” rather than “chmod”, and your workaround worked for me. I run most of my servers under user accounts, and I set the owner:group of the entire webdir to “<acct>:www-data”. (I then give group write access to those few dirs that need it, like wp-content/uploads.)

After the upgrade succeeded I changed ownership back to the way it started with “chmod -R <acct> /home/<acct>/webdir” .

What is more interesting is that I specifically gave group write access to all the files and folders at one point and the upgrade still failed. So the wrinkle is something specifically related to file ownership rather than just write access. This is quite strange and definitely something new with 4.5 (or, I suppose, maybe with Debian itself or with php).

Nice to have a reliable workaround, but I still wonder what the root cause is?

Yes sure I meant “chown” – sorry for that, can not even modify the post anymore to fix that

It also worries me that I have not yet found the underlying cause for the whole thing.

It still a problem having to chown all files before doing a core upgrade or even a plugin upgrade (or having to delete the .maintenance file if you don’t want to have the page inaccessible for 10 minutes)

Currently about 50 WP installations are affected by this here – so I need to find a definite solution for this to get back to the one click upgrades.

As I said all other WP instances (on wheezy distributions and SuSE distributions) work without any problems.

Do you all use FTP mode for the upgrades etc.?

Did anyone file a WP bug yet?

I do use ftp mode for updates/upgrades. I have not filed a WP bug report yet.

I’m curious about the .maintenance issue as well (which I also see). I wonder if simply giving www-data ownership of the webroot directory (temporarily, and not recursively) will solve this. With 50 sites I know that’s not a great solution, but it would definitely be another major symptom for a bug report if my suspicion is correct.

I’ll check that out myself with my next plugin update.

Just to follow up on my previous post, two of my plugins had updates released today. I tried just changing the ownership of the web site root directory and was still left in maintenance mode when the plugin updates were successfully completed. I had to manually remove the .maintenance file to restore normal operation.

On a second site that uses one of the same plugins I changed ownership of the whole web directory recursively and the plugin update worked 100% — not left in maintenance mode.

I’m off to investigate filing a bug report or at least talking about this problem in a developer’s forum.

I just filed a bug report — we’ll see what happens. You can head on over to the report if you want to chime in and say you are seeing the same behavior.

Tried again with 4.5.2:

Downloading update from https://downloads.www.ads-software.com/release/wordpress-4.5.2-no-content.zip…
Unpacking the update…
Verifying the unpacked files…
The update could not be unpacked
Installation Failed

This is very annoying. Bugs happen, but I find the silence of WP staff and developers here upsetting. Could you please say something?

I have many WP sites and no time for updating all manually.