I've attempted to set up my wordpress install as recommended in the Codex's "Hardening WordPress" article. That is:

  • All files are 644, all folders are 755
  • Everything owned by the user account
  • wp-content is writeable by the web server account (it's 775 and group-owned by apache's account)

The Codex document says auto-update should work with this setup. But in practice, when I try to update (from 4.2 to 4.31), I get the usual permission error (inconsistent permissions on update-core.php). If I temporarily change that file to be writeable by the web server account, then update gets past that step (and complains about permissions for a massive list of other files).

So as near as I can tell, it seems that auto-update can't proceed unless most of the files in wp-includes and wp-admin, are writeable by the web server process - which is exactly what the "hardening" article says to avoid.

Any guesses what the issue might be?


The point of hardening is to avoid the core files to be manipulated by external users (on shared hosting) and by the webserver (as it is the main source of exploits). Since the update runs via the webserver it is obvious that if you hardened your files against webserver initiated manipulation, the update will fail.

Most people probably get around it by using FTP to place the updated files (the update process imports a file from the update server and then uses the FTP protocol to actually write it instead of using the PHP file APIs). If you don't have FTP on your server then you are out of luck.

Secure settings are just not very friendly to updates, but IMO the cost of doing manual update (If you have SSH access then just use WP-CLI) once a month (if your plugins/theme are that bad) is worth the enhanced security.

  • The codex doc says that auto-update runs as the account that owns the files, not as the web server account. Source link is now added to the question. Are those docs wrong? – fenomas Nov 5 '15 at 6:48
  • It is hard to know in the codex when the writer misunderstands features or just a section is not written well. 644 means that only owner can write to the files, and since the update is triggered from the web server you will have to have the web server running under the same user for it to be able to directly use PHP to write to the files. If the web server runs under a different user it will fail. See also - wordpress.stackexchange.com/questions/5829/… – Mark Kaplun Nov 5 '15 at 7:11
  • Whoa, now I'm confused. So (non-ftp) auto-update explicitly requires a configuration that various docs say you should not use? Or to phrase that more usefully, are you saying that a security-conscious user should want auto-update to not work, and should only update manually? (This is for a single blog on a VPS - no sharing, other users, suexec, etc.) – fenomas Nov 5 '15 at 7:38
  • smart admins will never use auto update without testing that the update do not break anything, so while the ability of one click update is a nice things, the automatic one is BS (in the context of money generating site, for simple blogers on shared hosting the autoupdate is very good thing). In general you don't want the web server to have write access to anything which is not 777, but on shared hosting this kind of configuration might lead to users being able to read/write other users files which is bad, therefor the webserver needs to run as the user in that config. – Mark Kaplun Nov 5 '15 at 7:59
  • Apache version 2.4 IIRC lets you specify a user under which a virtual host is being executed and that is probably what you will need to do if you don't like su_exec but still want automattic updates. – Mark Kaplun Nov 5 '15 at 8:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.