I've been reading some posts that seem to touch on this (or possibly address it, but it's going over my head). Unix is not my strong suit by a long shot.

I have inherited a Fedora server that is a little bumpy when it comes to auto upgrades.

Two things I've noticed: 1. It prompts me for FTP user and password. I'd like to eliminate this WITHOUT resorting to hard-coding the credentials (for a number of reasons) 2. The most recent 3.3.1 update fails for permission reasons (earlier upgrades did not fail). The workaround is to sudo chmod -R g+w ./* in the main wp directory, but I'm kind of sick of doing that every time.

Bottom line: things WORK, but it's more work than I'd like.

Right now, everything seems to be running under the 'apache' user, which is a member of my 'developers' group that is the same group for the various people that FTP and make changes/edits to files/folders. But any new files/folders that are created by these users do not have their group write mode set so I have to do it manually...

Any thoughts? I'll need a bit of a step-by-step since I'm a unix moron.



  • Hmmm... This may be better on a different site... maybe unix.stackexchange.com? This isn't really a WordPress question, more of a unix/sysadmin type question... – John P Bloch Jan 25 '12 at 16:06
  • @JohnPBloch I disagree; questions about optimal configuration for ensuring a core WordPress feature - such as automatic upgrades - works properly/optimally should be in-scope for WPSE. – Chip Bennett Jan 26 '12 at 16:40
  • @ChipBennett Fair enough. I gladly concede the point. :) – John P Bloch Jan 27 '12 at 0:54

The simplest answer is:

As long as you're on a fairly standard RedHat/CentOS/Fedora server, make sure that everything under your WordPress directory belongs to apache:apache. This will prevent the prompting for FTP credentials.

The advantage to doing it this way is that, in almost ALL situations, Apache has /bin/false or /sbin/nologin set up as its shell. This prevents anyone from exploiting the apache user to gain shell access to your box.

I think you're likely getting tripped up by directories inheriting permissions from users with valid shells whose umasks are set funny. Try chown'ing everything to apache:apache and do a couple of test updates and see if that doesn't fix 99% of the issues you're running into.

  • Some distros (the Debian flavors, I believe) use www-data:www-data instead of Apache. Obviously, the OP would use apache:apache, but anybody reading this who's using Debian, Ubuntu, etc. will probably have to use www-data instead of apache. – John P Bloch Jan 27 '12 at 0:59
  • Right, but since he stated he's on a Fedora box, I was targeting such... grin – ZaMoose Feb 7 '12 at 21:34
  • Indeed. And right you were to do so. My comment was more for the edification of future Debian-based readers. ;) – John P Bloch Feb 8 '12 at 16:16
  • 1
    On our Centos server we use "nobody" as owner. Something like nobody:users does enable the automatic updates. +1 for pointing the way. – SPRBRN Sep 30 '13 at 9:10

The short answer is to enable suPHP on your server, so that WordPress can run as its own user, rather than as apache.

Otto explains more here.

  • Hey Chip, thanks for the response. I don't get why that will solve all my issues though. WordPress has no problem running under Apache, since Apache is part of the group that has the r/w permissions. It's a good workaround to the suPHP issue and IMO provides a little more control (and maybe security)? – Tom Auger Jan 26 '12 at 16:16
  • Did you read the link? Otto explains, in far greater detail than I could articulate. – Chip Bennett Jan 26 '12 at 16:30
  • I did, Chip, in fact I'd already read it quite thoroughly prior to writing this question, just in case the info I needed was in there. I'm quite sure that you're right and that suPHP would probably solve some of my problems, but I don't think it's the complete solution and my current workaround addresses that part of the problem adequately. – Tom Auger Jan 26 '12 at 16:35

The answer to this is rather complicated.

On a shared server (running more than one website), using an setuid process for PHP (via whatever means) provides extra intra-user security. If two people have access to a server, and their scripts run as them instead of as a single "apache" user, then somebody breaking into one site via the web only gains the privs of that user, not the privs of "apache", which will be greater (apache can see everybody's web files, for example, in order to run them, but "otto" can't see the files of "bob").

In this case, WordPress will be running as "otto" and not "apache". Since it's running as "otto" and the WP files are owned by "otto", then it can just write the files directly and doesn't need FTP credentials.

See, it's all about ownership. If the files are owned by the same user who WP is actually running as, then it will use the direct method. If not, then it has to fall back to the FTP method (or other), because the important thing during an upgrade is that file ownership does not change. If it tried to write them directly as the apache user, then "apache" would own the resulting files. Which might be a security risk on a dedicated server.

For a dedicated server, having the files owned by a non-apache user while having the PHP run under 'apache' is safest. Perhaps even setting up a special user just for owning those files might be preferable and securer in such a situation. Then the credentials to upgrade could be put into the wp-config file, and even if they were stolen in some manner, wouldn't pose a threat since those credentials could be locked down to where they had virtually no access to anything but the WP files themselves. Then if somebody did break in, they'd either break in as "apache" (which has limited privs) or be able to execute code as the custom WP user (which also has limited privs).

The idea is to limit the capabilities of a user who finds a hole in the system. When somebody finds a weak spot, then they will be further limited by the privileges of the user that the process they broke through with is running as.

  • I don't think it's a shared server -- I think it's a dedicated box (at least that's what I took from his description...). – ZaMoose Jan 26 '12 at 18:29

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.