我已使用以下行通过 fstab 安装了远程共享：
//path/to/target /media/f cifs gid=<mygroup's id>,dir_mode=0775,file_mode=0775 0 0
因此，下面的所有内容/media/f都会具有如下所示的权限：
$ ls -al
drwxrwxr-x 0 root mygroup ...
我已使用户成为www-data的成员mygroup，目的是允许 Django web 应用程序在 中写入文件/media/f。然而，这不起作用。我收到权限错误。
为了解决这个问题，我将安装线更改为设置两个都并gid让uid挂载点具有 userwww-data和 group mygroup。所以现在我的挂载点如下所示：
$ ls -al
drwxrwxr-x 0 www-data mygroup ...
一切都很好。
问题：为什么我的 web 应用程序能够在/media/f该文件夹归其所有时写入www-data:mygroup，但在该文件夹归其所有时却不能写入root:mygroup（知道该文件夹www-data是 的成员mygroup）
我尝试重新安装并重新启动，希望让www-data（用户）的组成员身份mygroup“粘住”，但它不起作用。
奇怪的是，当设置root:mygroup所有权时，如果我sudo su www-data然后尝试从终端写入/media/f，一切正常。知道那里发生了什么吗？就好像uwsgi运行 django 的进程并未真正以我尝试授予的完整权限运行www-data。
想法？
答案1
事实证明，这对于上述上下文来说是非常具体的。我使用 uWSGI 使用皇帝模式为我的网站提供服务。我设置了参数uid=www-data和gid=www-data。我预计这会导致我的附庸进程拥有与用户和组关联的权限www-data 也www-data与（用户）所属的任何组关联的权限。这个假设是不正确。封臣不运行（默认情况下）任何补充组 ID。
事实证明，uWSGI（在最近的版本中）已经解决了这个问题。您可以add-gid=mygroup在uWSGI配置中手动指定。您可以多次指定此参数，以便根据您的意愿向 vassal 进程添加任意数量的 gid。此功能仅从 uWSGI 1.9.15 起可用，因此您可能需要升级才能使用此方法。
完整的书面记录这里。