我有一个我认为非常正常、非常典型的用例。我很惊讶（到目前为止）似乎还没有解决方案。我想我忽略了一些显而易见的事情。许多人肯定需要针对此用例的解决方案。
同一组中最多五个不同的用户在一台计算机上拥有登录帐户。他们并非同时登录。
更新 1：这些文档是驻留在我们本地服务器上的文本文件和电子表格。我们不想在 Google 或任何外部服务器上托管文档。
我们的确是不是需要实时协作。
“团队”组中的这些用户需要通过读取和写入共享目录中的文件来进行协作。包含这些文件的目录位于本地服务器上。共享目录可以通过标准Linux方法挂载到客户端。如果需要，我们可以使用 ACL，因为 BTRFS 具有内置支持。
所有用户都可以使用密钥通过 SSH 登录服务器。客户端和服务器上的用户和组 ID 相同。所有用户都没有 sudo 权限或任何其他特殊权限。他们的共同点是“团队”组的成员身份。
共享目录不在任何用户的主目录下。它由具有 rwx 权限的同一组“团队”拥有，并且“团队”中的所有用户都可以完全访问它的路径。我们可以根据需要更改权限，但是“团队”组之外的任何用户都不能读取或写入此目录中的文件。
客户端和服务器都运行 Arch Linux，并且都运行 BTRFS。
我们尝试 NFS 大约十年了，遇到了许多权限/访问问题。我们最重要的支持问题之一是解决用户的权限问题。我们决定放弃 NFS，因为我们从未找到解决权限问题的良好解决方案。
我们切换到 SSHFS 因为“我们可以使用普通的文件系统权限”。到目前为止，我们还无法使用 SSHFS 实现上述简单目标。看这里和这里。
我们没有听到很多关于 Samba 的好消息，所以我们从未尝试过。那里还有什么？
这似乎是一个常见的用例。一般情况下会怎样解决呢？
我们甚至没有一个复杂的案例。例如，我们网络中的所有机器（服务器和客户端）都运行 Linux。所有机器都位于本地 LAN 上。这很简单。但我还没有找到可行的解决方案。
答案1
这实际上相当容易。大多数人似乎认为他们需要设置给定目录下所有文件的权限，但事实并非如此。只需顶级目录即可：
chown :team /path/to/dir
chmod 2770 /path/to/dir
首先，我们将组所有者设置为team您所说的组，该组已经存在并且包含应该能够访问正确目录的人员。接下来，我们将权限设置为目录上的“设置组 ID”（因此在该目录下创建的任何文件team也将归该组所有；不是绝对必要的，但我发现这是一个有用的提醒），并给出完整的team组中任何人以及目录所有者的权限。任何人不是该组中将有others权限，此处为空。
此设置的结果将是，对于不在该team组中的任何人，即使在该目录上执行操作ls也会得到Permission denied.那些人是但是，如果没有将文件单独设置为错误的文件权限，则正确组的成员将能够在该目录中读取和写入。如果不应保护此类文件免遭写入，请立即更正权限：
chmod -R g+rw /path/to/dir
find /path/to/dir -type d -print0 | xargs -0 chmod g+x
在没有 ACL 的情况下，您无法通过创造性地设置权限位来为将来（即新创建的）文件设置权限。用户需要设置他们的umask。您可以通过以下行来完成此操作/etc/profile：
umask 002
设置这一点很重要，因为许多发行版上的默认值是 022（允许组成员读取，但不允许写入）、077（允许没有什么给其他用户），或 027（允许读取，但不允许写入，组；其他人无权）。这些选项都不是您想要的。
如果您对文件系统的不同部分有不同的要求，或者您想确保人们不会通过单独摆弄其 umask 来搞砸事情，您可以使用默认 ACL：
find /path/to/dir -type d -print0 | xargs -0 setfacl -m d:g:team:rwx -m d:o:---
一旦你把一切都设置好了，它真的不要紧无论您使用 SSHFS 还是 NFS。但是，如果仍然不起作用，最好回来提出更具体的问题
答案2
根据文档的内容，要么使用适当的版本控制系统，例如git所有人都可以访问的存储库（有利于软件协作），要么使用 Google Docs 等允许协作编辑文本文件的系统（有利于协作编辑文本文件）。例如报告）。这些是我当前工作场所使用的解决方案。
另请参阅维基百科条目协作实时编辑器。
恕我直言，同时编辑文档共享驱动器这是有问题的，因为一个用户保存的文档很容易覆盖另一用户所做的更改。也无法跟踪谁进行了哪些更改或将更改回滚到文档的早期版本。