1

I'm setting up a couple of wordpress installs and am habitually running into permission problems. I suspect the main problem is that I'm not a shared hosting environment, just a plain Ubuntu VM and so whatever the default settings are on Ubuntu is not what WP expects. Examples of problems:

  1. upgrades fail because apache doesn't have write permissions to the wp install
  2. themes and other uploads fail because new folders created have the wrong group membership or permissions
  3. cannot create directory wordpress/wp-content/upgrade

So far I've had to alter the default umask for apache to fix 2, chmod a setgroupid bit to fix 1, and I'm now looking into 3. My guess is that it's not supposed to be this hard. Am I missing some huge obvious configuration settings?

I set up a wordpress install with a user per class, to limit collateral damage while allowing teamwork and tinkering, so chmod 777 and other head-in-sand approaches are worse than the status quo.

2
  • Which install guide did you follow? I've been using Debian 5 and WordPress up-to-and-including-3 (official package, not Debian's) without issue. Update, plugin, theme installs all work.
    – jscott
    Aug 26, 2010 at 18:57
  • I followed Wordpress's official guide. Ubuntu 10.04 has some configuration differences that are fun, including things like disabling PHP on userdir, but I've learned the hard way not to follow averages users and whoever's responsible for the Debian WP package abonination.
    – jldugger
    Aug 26, 2010 at 19:38

2 Answers 2

1

For upgrades I chown all the files/dirs to the user the web server runs as, do the upgrade, then chown them back to root. Upgrading is no longer point and click but worth the price IMHO. Webserver-user-writable PHP files make me cringe. Some dirs under wp-content may need to be always writable by the the user the web server runs as.

Alternately, you could refrain from doing an online upgrades and let the Ubuntu update system handle the upgrades, assuming you used it to install WP initially.

http://codex.wordpress.org/Changing_File_Permissions says:

NOTE: For the Automatic Upgrade/Install of Plugins/Themes and WordPress Upgrades, No special permissions need to be set. All WordPress files should remain owned by your user account, You should NOT have to make them world writable(777). If you attempt to change the ownership/permissions of files in order to allow the upgrader to work, There is a high chance of bugs/issues poping up related to the incorrect permission scheme chosen.

For core WordPress files, all should be writable only by your user account.

That is wrong. How can the upgrade replace core files if the webserver user cannot write to them? How can it add new files if it can't write to the dir?

1
  • The Debian/Ubuntu WP package was pretty terrible when I checked. Not at all what users were expecting. Perhaps the 3.0 multiblog feature has encouraged the removal of some of the more silly Debian patches. So no, I installed from source rather than via Debian. Using apt to install the package dependencies was helpful though.
    – jldugger
    Aug 26, 2010 at 20:40
0

Unfortunately it more or less is supposed to be this hard.

The cost of LAMP's infinite flexibility is its infinite permutations and the inevitable regressions and entropy that come with that. Different people use different distros, use different packages within those distros, follow different guides/howtos/blogposts, use different directories, and use different features and plugins. Layer versioning differences of each component on top of that and you have a situation where in effect almost no two wordpress blogs ever are configured the same.

Your options are
- do it yourself, deal with every little thing on an ad-hoc case by case basis
- live within the preconfigured decisions of a shared-hosting setup (even if on your own vps)
- pay for a professional service like wpengine.com
- pay for a sysadmin to deal with all of it

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .