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

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

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

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

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

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

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

不要使用

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

采用

• /home用于用户主目录。有些人也将此目录视为组文件的区域。FHS实际上指出，“在大型系统上（尤其是当使用NFS在许多主机之间共享/ home目录时，对用户主目录进行细分非常有用。可以通过使用/ home / staff，/ home等子目录来实现细分。 /来宾，/ home /学生等。”
• /srv是组文件的可接受位置，通常是首选位置。由于Chris Down的回答中提到的原因，我通常将此目录用于组共享文件；我认为组文件共享是服务器提供的一项服务。

有关man hierFHS所描述的每个目录用途的更多信息，请参见hier（7）手册页（）。

我认为正确的位置是/srv/movies-enthusiast。“服务”不必是守护程序或程序，而只需是系统提供的服务（例如能够将电影放到那里）。这是FHS的报价：

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

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

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

因为它是您的名称空间，所以您应该选择任何您认为合适的名称。如果发现/groups/movies-enthusiast合理，则应将其放在此处。如果您喜欢短路径名，因为它更容易键入，那么/g/movies-enthusiast（或者也许/g/m-e）将是合适的。

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

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

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

特别是如果这是该系统的主要目的，我将创建

/电影爱好者

如果还有其他类似的“组”，我可能会或可能不想将它们托管在一起，例如

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

要么

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

要考虑的问题：您是否打算为此使用专用的挂载点？

您是否考虑过软链接？

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

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

FHS还可以简化管理员，因此出于这个原因，我会选择/ srv，尽管我没有这样做。尽管有完善的后见之明。我使用/ export / srv，因为它在NAS上。

如果是放置框，请确保它既固定又粘。还请确保使用它的用户具有有用的umask。但是，不要像我在文件访问模式示例中所做的那样使用wheel。不要剥夺eXecute，否则您会感到意外。

bash-3.2$ mkdir movies
bash-3.2$ sudo chmod 03771 movies
Password:
bash-3.2$ ls -ld movies/
drwxrws--t 2 andrewb wheel 68 Apr  4 17:09 movies/
bash-3.2$ umask 026
bash-3.2$ touch movies/junk
bash-3.2$ ls -l movies/
total 0
-rw-r----- 1 andrewb wheel 0 Apr  4 17:09 junk

重要的是要记住，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>。有时它们也将是部门的子部门；还是，你明白了。老实说，我个人不喜欢这种策略，但是当/home在多个服务器之间分发（例如，通过NFS）时，它使事情变得容易一些，这就是为什么它在大型组织中倾向于使用的原因。

我个人选择/ usr / share / movies-enthusiast或/ opt / movies-enthusiast

我建议创建一个单独的目录，例如/ opt / movies，为它们设置适当的用户和组权限，也可以使用磁盘quota来避免总磁盘消耗。

这既是评论，也是答案（因此，请不要为我投反对票！），但评论太长了。

我做了两件事，都避免了您遇到的问题。

1）我对系统磁盘上的所有可用空间进行了单独的分区，并将其标记为数据空间。那是我当前所有媒体文件和其他数据的存放地。它被自动挂载为/ media / dataspace，我将“ data”中的任何内容放在“ data”目录下，以将其与我不想定期备份的工作文件，vms或iso映像等分开。

使用单独的分区还有一个额外的好处，即如果分区满了，它不会像存储在/或/ home下那样破坏我的系统。

2）我将大部分数据/媒体（尤其是我现在不使用的东西）放在另一个物理驱动器上（在我的笔记本中为USB）。这样可以轻松进行备份，并在需要时易于附加到另一台计算机。