btrent98

Glad to see you are working on a fix for this as I am experiencing the same issue. It is more of an annoyance, I think, as it appears that I actually AM logged out when this message appears. I presume it is complaining about the redirected login url which includes a “custom” string that is a separate WP-Cerber security feature?

That was it — there was no .htaccess file there at all! I copied the .htaccess file from another working site (which was extremely similar but not identical to the one you posted) and everything works fine now. Thanks for your help and for creating and maintaining this great plugin!

Just for the record, the contents of my .htaccess file are:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

I set the Custom URL to “mungo” again. After logging out the URL in the browser looks reasonable:

https://www.trentartglass.com/mungo/?action=logout&_wpnonce=8ce3cdd822

but I still get the same “404 Not Found” page for that URL. It also seems that perhaps the logout was not really successful? I can use the back button from that 404 page and I go back into the WordPress dashboard where I can change the Custom URL back to null. This is probably good — at least I’m not locked out! (Although I do know how to recover from being locked out by manually removing the plugin files…)

No, the plugins vary a bit from site to site but for this test I turned every plugin off except Akismet. As for the “exact page” when I try to open the Custom URL, it is as I described above. I set the Custom URL value to “mungo”. When I go to https://www.trentartglass.com/mungo I get a “404 Not Found” page that says:

Not Found

The requested URL /mungo was not found on this server.
Apache/2.4.10 (Debian) Server at https://www.trentartglass.com Port 80

Got it:

[REQUEST_URI] => /wp-admin/options-general.php?page=cerber-settings&tab=tools

Any other diagnostic info I can give you?

I’m not using any caching plugins. I disabled any plugin that was specific to the site in question (that is, not used on one of my other 5 sites that work fine). I set the Custom URL value to “mungo”. When I go to https://www.mywebsite.com/mungo I get:

Not Found

The requested URL /mungo was not found on this server.

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.

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 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.

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?

I’m trying to come up with a common thread for those of us having this problem. We are all running Debian Jessie, right?

Are any of you running the WordFence security plugin by chance?

I’m having exactly the same problem on my Debian Jessie server which serves multiple wordpress sites using separate installs. Installation fails (“The update could not be unpacked”) and .maintenance is not removed after updating plugins.

I am a longtime user and the automatic update has never failed on this machine before.

Like mash33 I’ve tried changing permissions with no success and the /tmp folder is definitely not full.

I’m confident I could perform a manual update but that’s not really the point — something is broken and it’s obviously not just me.

Is there some way to turn on logging or some other way to debug this problem? Is there a developers forum where I might file a bug report?