所以，我有一个带有“部署”用户的盒子。该部署用户拥有一个代码存储库，并且 WordPress 正在该机器上运行......
当 wordpress 尝试执行诸如上传插件之类的操作时，它正在使用用户“www-data”写入“wp-content/plugins”。显然，它正在上传 zip 文件，取消存档，然后删除 zip 文件。
我一直遇到 wordpress 无法执行这些操作的问题。由于我的整个代码存储库被设置为所有者和组：“deploy:deploy”，显然 www-data 无法访问它。
因此，我的第一次尝试是将 www-data 添加到部署组。
usermod -a -G deploy www-data
发出此命令后，我立即发现我无法再通过 ssh 进入该盒子。我完全困惑于为什么——任何人都可以告诉我这一点吗？所以我最终做了：
chmod -R go-w ~
然后可以再次 ssh...执行“groups www-data”显示部署作为选项之一，所以我想万岁...我去确保 wp-content 和插件目录都对该组具有写访问权限，他们做到了......双倍霍雷，它应该完美地工作！
但是，没有...尝试上传插件失败。
经过一番烦恼之后，我只是进入 apache 配置并将 APACHE_RUN_USER & GROUP 更改为“部署”
问题解决了……算是吧。除了 apache 作为主用户运行的想法之外，我认为很糟糕。
无论如何，进行此更改后，上传插件成功，我看到：
drwxr-xr-x 8 deploy deploy 4096 Oct 22 21:28 wp-crm
所以，该组没有写访问权限——我想这可能是一个提示，说明为什么会失败...但是，事实上，它是用部署编写的，这意味着这并不是真正的提示...因为这只是由于部署的 umask 如何设置为..我假设...
所以...我只是不知道解决方案是什么...
我的 wp-content 组应该改为 www-data 吗？
或者我在这里还缺少其他东西吗？
答案1
最简单的解决方案是文件系统 ACL。我不确定我是否同意该设置（因为该目录不是静态的，并且它没有使用其他目录来存储临时数据），但这是另一回事。
使用文件系统 ACL，您可以授予www-data用户对特定目录的访问权限，即使普通权限不允许。
例如
setfacl -R -m user:www-data:rwx wp-content/plugins
setfacl -d -R -m user:www-data:rwx wp-content/plugins
第一个命令授予www-data读+写+执行权限wp-content/plugins以及其中的所有内容（递归地）。第二个命令设置默认权限，以便在 中创建的任何新文件和文件夹wp-content/plugins都将具有指定的 ACL（因此可以由 读+写+执行www-data）。
答案2
很遗憾usermod -G 取代用户组。你想要usermod -G -a。