我们的用户经常请求共享磁盘空间，以便与一组用户一起使用，以便交换或处理某些文件。为了能够利用配额管理，我们创建了一个新用户帐户（配额受控），并授予该用户组对该用户主页的访问权限。我其实不喜欢这种方法。我们如何构建一个灵活的解决方案，使我们能够在启用配额控制的情况下根据需要为某些用户提供一定数量的空间？
（我想到的一个解决方案是大量使用 LVM 来为每个组创建一个新的分区（lv），但我不确定它如何扩展。）
答案1
我是“软配额”的粉丝。硬配额和磁盘限制可能会影响工作能力，比如说，如果他们有一天真的需要 30 G 的空间来做一些大型项目。在我的公司，我们有一个非常简单的脚本，它可以从 AD 中抓取所有用户，SMB 挂载他们的主目录并进行大小计算。此脚本附带一个标准配额限制（对我们来说是 2G），以及一个例外列表。
如果他们违反了配额，他们和管理层都会收到一封电子邮件通知，告知他们的目录大小以及配额。
它并不适用于所有环境或所有规模，但当您有硬性配额限制时，它可以降低生产力。
答案2
根据我的经验，最大的问题是：
配额
我们定义了“项目”目录并使用 XFS 项目配额来强制执行配额。我们同时应用软配额和硬配额，并且有脚本在用户达到软配额时通过电子邮件提醒用户。使用 XFS 可以轻松做到这一点。
权限
权限似乎总是一个巨大的问题。我们现在使用 ACL 来确保组中的所有成员都可以访问创建的所有文件，但是当我们将目录共享给不理解这些 ACL 的计算机时，或者当程序创建具有明确狭窄权限的文件时，就会出现问题。我们最终会得到没有正确 ACL 的子目录，然后用户抱怨他们无法编辑其他人创建的组文件夹中的某些项目。这导致每个人都感到沮丧并对chmod -R 777 *他们拥有的一切感到不满。似乎大多数人都希望组文件夹具有一组权限，这些权限同样适用于所有后代文件系统对象。
为了实现这一点，我们有一个名为权限破坏者它会定期遍历所有项目目录并修复所有文件系统对象的权限（标准权限和 ACL 权限）。所有内容都具有相同的权限级别（尽管它保留了可执行位），并且权限在版本控制的配置文件中定义。这让我们能够很好地确保用户不会在不知情的情况下绕过访问控制，从而将访问权限授予错误的人。
在我们的 Mac OS X 服务器上，这要容易得多。HFS 具有可以覆盖所有后代文件系统对象的 ACL 的 ACL。更棒的是，它们应用于服务器端，因此不理解 HFS ACL 的客户端（例如 Linux NFS 客户端）也可以按预期工作。我们只需在组目录本身上定义 ACL，其所有内容始终统一提供给整个组。
问责制
另一个棘手的问题是谁最终负责存储在组/项目目录中的数据。数据往往会在其中积累和腐烂，因为没有一个人负责保持数据的整洁。当达到配额时，有时很难找到合适的人来通知。为了解决这个问题，我们尝试为每个目录指定一个用户作为维护者。
答案3
我们使用单独的分区来存储群组共享数据。然后，我们设置了群组配额，每个群组都有一个目录。我们还将目录设置为 setgid，这样新创建的文件将继承群组的权限。这可能不是一个完整的解决方案，但可能是一个有用的开始。
答案4
如果您可以做到，请使用 Solaris（或 OpenSolaris）机器作为文件服务器。ZFS 和更高级的 NFSv4 ACL 远远超出了您使用 Posix 权限、Posix ACL、LVM 等所能做的事情。即使客户端不使用 NFSv4，ACL 仍将由 ZFS 强制执行和传播，只需从服务器进行管理即可。在大多数情况下，这实际上可能更好，因为复杂性对最终用户来说是隐藏的。
然后，您可以轻松地为每个操作组、项目或任何内容创建 ZFS 文件系统，并根据需要分配配额和配额策略。
这是迄今为止我见过的用于此目的的最灵活的系统类型，但当然并不适用于所有环境。