我正在设置几个wordpress安装，并习惯性地遇到权限问题。 我怀疑主要的问题是，我不是一个共享的宿主环境，只是一个普通的Ubuntu虚拟机，所以无论默认设置在Ubuntu上是不是WP期望。 问题的例子：
到目前为止，我不得不修改Apache的默认umask修复2，chmod setgroupid位修复1，我现在正在调查3.我的猜测是，它不应该是这么难。 我是否缺less一些明显的configuration设置？
我为每个class级的用户设置了一个wordpress安装程序，以减less附带的伤害，同时允许团队合作和修补，所以chmod 777和其他头部入侵方法比现状更糟糕。
对于升级，我将所有文件/目录分配给Web服务器运行的用户，执行升级，然后将其重命名为root。 升级不再是点和点击，但价值恕我直言。 Web服务器用户可写的PHP文件让我畏缩。 在wp-content下的一些dirs可能需要总是可以由web服务器运行的用户写入。
或者，您可以避免进行在线升级，并让Ubuntu更新系统处理升级，假设您最初使用它来安装WP。
http://codex.wordpress.org/Changing_File_Permissions说：
注意：对于插件/主题和WordPress升级的自动升级/安装，不需要设置特殊的权限。 所有的WordPress文件应该保持你的用户帐户所有，你不应该让他们世界可写（777）。 如果您尝试更改文件的所有权/许可权以允许升级程序正常工作，则与所选不正确的权限scheme相关的错误/问题出现的可能性很高。
对于核心WordPress文件，所有文件只能由您的用户帐户进行写入。
那是错的。 如果Web服务器用户无法写入，升级如何取代核心文件？ 如果无法写入目录，它如何添加新文件？
不幸的是，它或多或less应该是这个难题。
LAMP的无限灵活性的代价是它的无限排列和不可避免的回归和熵。 不同的人使用不同的发行版，在这些发行版中使用不同的包，遵循不同的指南/ howtos / blogposts，使用不同的目录，并使用不同的function和插件。 在上面的每个组件的层次版本差异，你有一个情况，实际上几乎没有两个WordPress的博客configuration相同。
你的select是
– 自己动手，根据具体情况处理每件小事
– 在一个共享主机设置的预先设定的决定（即使在你自己的VPS）
– 支付像wpengine.com这样的专业服务
– 支付系统pipe理员处理所有这一切