Каков самый соответствующий каталог, куда поместить файлы, совместно использованные между пользователями?

По-моему, правильное место /srv/movies-enthusiast. "Сервис" не должен быть демоном или программой, это просто должна быть услуга, которую система предоставляет (такие как способность получить Ваши фильмы там). Вот кавычка от FHS:

/srv содержит сайт-специфичные данные, которые подаются этой системой.

Я определенно думаю, что Ваше использование подпадает под то определение и предоставляет услугу.

Стандарт иерархии файловой системы (FHS) указывает расположение для "Разработчиков распределения Unix, разработчиков пакета и системных конструкторов" для соблюдения того, для не создания путаницы пространства имен.

Поскольку это - Ваше пространство имен, необходимо выбрать любое имя, которое Вы чувствуете, подходит. Если Вы находите /groups/movies-enthusiast имеет смысл, необходимо поместить его там. Если Вам нравятся имена короткого тракта, потому что их легче ввести, /g/movies-enthusiast (или возможно /g/m-e) подошло бы.

Поскольку пути, которые Вы выбираете, не определяются в FHS, распределение или сторонние пакеты не должны касаться их. По сути, необходимо считать FHS для знания, какие пути могут использоваться совместимым программным обеспечением (оглавление скажет Вам большую часть того, что необходимо знать).

Например, я лично использую /av поскольку, где я храню свое аудиовизуальное содержание, /src для исходного кода и /data для неопределенных данных (таких как виртуальная машина отображает, изображения CD, chroots, сохраненные пакеты, и т.д.).

Нет ничего неправильно с созданием новой точки монтирования или каталога с этой целью от корня.

Особенно, если бы это - основная цель этой системы, я просто создал бы

/movies-enthusiast

Если существуют другие подобные "группы", я могу или не могу предпочесть размещать их вместе, например,

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

или

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

Вопросы рассмотреть: Вы собираетесь выделить точку монтирования с этой целью?

Вы рассмотрели softlinks?

В любом случае нет никаких правил. Если Вы хотите сделать одного пользователя хранителем и предоставить остальным доступ к этому пространству проекта, не стесняйтесь размещать его в корневом каталоге пользователя. Или создайте/home/shared /* пространство имен. Вы - свой собственный босс.

О, одна вещь: Независимо от того, что Вы делаете, действительно зарегистрируйте его. Это должно стать частью системного восстановления, ежедневно проверок, резервных копий, и т.д. Важная конфигурация задерживает потребность, которая будет отмечена (например, составы группы, наборы полномочий, фс tunables для производительности и чего-либо еще, что не является значением по умолчанию),

FHS должен также сделать администратора легким, таким образом, я пошел бы с/srv по этой причине, хотя не, что я сделал. Имейте идеальную непредусмотрительность все же. Я использую/export/srv потому что на NAS.

Если это - поле отбрасывания, затем удостоверяются, что это - и setgid и липкий. Также удостоверьтесь, чтобы у тех, которые используют его, был полезный umask. Однако не используйте колесо, поскольку я сделал в примере режимов доступа к файлу. Не разделяйте выполняются, или Вы будете в для a O_o удивления.

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

Я лично выбрал бы/usr/share/movies-enthusiast или/opt/movies-enthusiast

Я предлагаю создать отдельный каталог как/opt/movies, установить соответствующего пользователя и полномочия группы для них, и также можно использовать диск quota для предотвращения общего диска используют..

Это - так же комментарий как ответ (поэтому не делайте downvote меня для него!), но это слишком длинно для вписываний в комментарий.

Я делаю две вещи, обе из которых избегают проблемы, с которой Вы сталкиваетесь.

1) Я делаю отдельный раздел всего свободного пространства на моем системном диске и маркирую это пространством данных. Это - то, куда все мои текущие медиа-файлы и другие данные идут. Это автосмонтировано как/media/dataspace, и я поместил что-либо, что это - "данные" в соответствии с каталогом, названным "данными" для разделения его от вещей как рабочие файлы, vms, или изображений ISO, которые я не хочу обычно копировать.

Используя отдельный раздел обладает дополнительным преимуществом, которое, если оно заполняется, оно не ставит под угрозу, моя система как оно была бы, если оно было сохранено под / или / домой.

2) Я поместил большинство своих данных/медиа, особенно вещи, которые я не использую "прямо сейчас" на другом физическом диске (USB в моем случае с ноутбуком). Это помогает скопировать и легкий подключить к другому компьютеру, должен потребность возникать.

Важно помнить, что 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 ), поэтому ее предпочитают в очень крупные организации.