放置用户之间共享文件的最合适目录是什么？

Question

或者：我可以把属于一个组的文件放在哪里？

假设 Unix 系统上有两个用户：joe和sarah。他们都是电影爱好者团体的成员。我应该把他们的电影文件放在哪里？

• /home/{joe,sarah}/movies不合适，因为这些目录属于joe / sarah，而不是属于他们的组；

• /home/movies-enthusiast也不合适，因为电影爱好者是一个群体，而不是一个用户；

• /var/movies-enthusiast 可能是一种选择，但我不确定 FHS 是否允许这样做；

• /srv/movies-enthusiast 也可能是一种选择，但是电影不是系统服务所需的文件。

Answer 1

不要使用

• /usr用于可共享的只读数据。此处的数据仅应出于管理原因（例如安装新软件包）而更改。
• /opt 通常用于自包含或出于某种原因需要与系统其余部分隔离的程序（例如，低和中交互蜜罐程序）。
• /var用于“在系统正常运行期间其内容预计会不断变化的文件——例如日志、假脱机文件和临时电子邮件文件”。我喜欢这样想：如果您的数据在列表中汇总起来看起来不正确，则它通常不属于/var（尽管如此，也有例外。）

用

• /home用于用户主目录。有些人将此目录也视为组文件的区域。FHS 实际上指出，“在大型系统上（特别是当 /home 目录在许多使用 NFS 的主机之间共享时），细分用户主目录很有用。细分可以通过使用 /home/staff、/home 等子目录来完成/guests、/home/students 等。”
• /srv是组文件的可接受且通常首选的位置。由于 Chris Down 的回答中提到的原因，我通常将此目录用于组共享文件；我将群组文件共享视为服务器提供的一项服务。

有关man hierFHS 描述的每个目录的用途的更多信息，请参阅 hier(7) 手册页 ( )。

Answer 2

在我看来，正确的地方是/srv/movies-enthusiast。“服务”不一定是守护进程或程序，它只需要是系统提供的服务（例如能够将您的电影放在那里）。这是FHS的引述：

/srv 包含此系统提供的特定于站点的数据。

我绝对认为您的用法属于该定义，并提供服务。

Answer 3

该文件系统层次标准（FHS）指定“Unix发行开发商，开发商封装和系统实现者”要坚持为了不使乱七八糟的布局你的命名空间。

由于它是您的命名空间，您应该选择任何您认为合适的名称。如果你觉得/groups/movies-enthusiast有意义，你应该把它放在那里。如果你喜欢短路径名，因为它们更容易输入，/g/movies-enthusiast（或者/g/m-e）将是合适的。

由于您选择的路径未在 FHS 中定义，因此发行版或第三方软件包不得触及它们。因此，您应该阅读 FHS 以了解兼容软件可能使用的路径（目录会告诉您大部分需要了解的内容）。

例如，我个人/av用于存储我的视听内容、/src源代码和/data未定义数据（例如虚拟机映像、CD 映像、chroot、保存的包等）。

Answer 4

为此目的从根创建新的挂载点或目录没有任何问题。

特别是如果这是这个系统的主要目的，我只会创建

/电影爱好者

如果还有其他类似的“组”，我可能会也可能不会喜欢将它们放在一起，例如

/data/movies-entusiast
/data/next-group
etc

或者

/share/movies-enthusiast
/share/next-idea
etc

需要考虑的问题：您是否打算为此专门设置一个挂载点？

你考虑过软链接吗？

在任何情况下都没有规则。如果您想让一个用户成为保管人并让其余用户访问此项目空间，请随意将其托管在用户的主目录中。或者创建一个 /home/shared/* 命名空间。你是你自己的老板。

哦，有一件事：无论你做什么，都要记录下来。它需要成为系统恢复、日常检查、备份等的一部分。 需要注意重要的配置保留（例如组成员身份、权限集、fs 性能可调参数，以及任何其他非默认设置）

Answer 5

重要的是要记住，FHS解决的是需要在多方（例如本地站点、发行版、应用程序、文档等）之间协调文件放置的问题；FHS 不会尝试为您可能遇到的每种情况设置规则：本地文件的本地放置是一个本地问题（FHS 3.0，第 1.1 节）。

因此，从技术上讲，您可以将movies目录放在任何地方，只要不违反 FHS 约定即可。不过，您的问题是关于最合适的位置，所以让我们考虑一些常见的答案（根据您的具体用例，从最喜欢的到我不太喜欢的排序）：

• /<someprefix>/<groupname>或者/media/<volumename>/<groupname>：老实说，我不知道为什么这个选项在 Linux 世界中名声不好，但让我们明确一下：这确实是您的系统，并且 FHS 表示您可以在根级别创建新目录，只要因为您不会与任何有明确语义的事物发生冲突。例如，您可以创建一个目录/groups或/shared根据您认为合适的方式在其中组织文件。我知道一些管理员更喜欢将它们与文件系统的其余部分隔离，因此他们安装一个不同的卷（即在 下/media/<volumename>/<groupname>）。两者都很好，而且都符合 FHS，真的。

• /srv/<groupname>或/srv/<someprefix>/<groupname>：根据 FHS，/srv包含由该系统提供服务的站点特定数据。FHS 随后继续解释说，用于命名 /srv 子目录的方法尚未指定。根据我个人的经验，大多数利用该/srv目录的管理员都会使用每个客户端、每个站点或每个项目的子目录，然后将数据目录放在该级别。无论您如何构建它，/srv如果您可以合理地认为共享这些文件本身就构成了一项服务，那么存储要在多个用户之间共享的文件是完全可以接受的。问问自己：“最终通过 SMB/NFS/AFS/GIT/... 共享这些文件有意义吗？” 如果是这样，那么您可以合理地认为您的目录是本地文件共享服务，从而将它们存储在 的子目录中/srv，即使没有守护程序实际将这些文件提供给其他系统。

• /home/<groupname>或者/home/<some-prefix>/<groupname>：FHS 说：/home是一个相当标准的概念，但它显然是一个特定于站点的文件系统。绝对不要求下面的每个目录/home都是实际用户的名称，并且可以接受组的子目录，但需要采取预防措施以避免组和用户之间最终发生冲突。尽管如此，我还是看到这种策略在几个大型机构（特别是大学）中使用，并采用了一些划分策略来避免冲突的可能性；例如，真实用户的主目录将放在/home/students/<studentid>、/home/teachers/<username>或中/home/staff/<username>，而共享内容将放在 中/home/workgroup/<workgroupname>。有时它们也可能是一个部门的分支；不过，你明白了。老实说，我个人不喜欢这种策略，但是当分布在多个服务器之间（例如通过 NFS）时，它会让事情变得更容易/home，这就是为什么它在非常大的组织中往往是首选的。