What's the most appropriate directory where to place files shared between users?

Question

Or: where can I put files belonging to a group?

Suppose there are two users on a Unix system: joe and sarah. They are both members of the movies-enthusiast group. Where should I put their movie files?

• /home/{joe,sarah}/movies are not appropriate because those directories belongs to joe / sarah, not to their group;

• /home/movies-enthusiast is not appropriate too, because movies-enthusiast is a group, not a user;

• /var/movies-enthusiast might be an option, but I'm not sure this is allowed by the FHS;

• /srv/movies-enthusiast might be an option too, however movies are not files required by system services.

Answer 1

Don't use

• /usr is for sharable read-only data. Data here should only change for administrative reasons (e.g. the installation of new packages.)
• /opt is generally for programs that are self-contained or need to be isolated from the rest of the system for some reason (low and medium interaction honeypot programs, for example).
• /var is for "files whose content is expected to continually change during normal operation of the system---such as logs, spool files, and temporary e-mail files." I like to think of it like this: if your data wouldn't look right summarized in a list, it generally doesn't belong in /var (though, there are exceptions to this.)

Use

• /home is for user home directories. Some see this directory as being an area for group files as well. The FHS actually notes that, "on large systems (especially when the /home directories are shared amongst many hosts using NFS) it is useful to subdivide user home directories. Subdivision may be accomplished by using subdirectories such as /home/staff, /home/guests, /home/students, etc."
• /srv is an acceptable and often-preferred location for group files. I generally use this directory for group-shared files for the reason mentioned in Chris Down's answer; I see group file sharing as being a service that the server provides.

See the hier(7) man page (man hier) for more information of the purpose of each directory described by the FHS.

Answer 2

In my opinion, the right place is /srv/movies-enthusiast. A "service" does not have to be a daemon or program, it just has to be a service that the system provides (such as being able to get your movies there). Here's a quote from the FHS:

/srv contains site-specific data which is served by this system.

I definitely think your usage falls under that definition, and provides a service.

Answer 3

The Filesystem Hierarchy Standard (FHS) specifies a layout for "Unix distribution developers, package developers, and system implementors" to adhere to in order not to make a mess of your namespace.

As it is your namespace, you should choose any name you feel is suitable. If you find /groups/movies-enthusiast makes sense, you should put it there. If you like short path names because they are easier to type, /g/movies-enthusiast (or perhaps /g/m-e) would be suitable.

Because the paths you choose are not defined in the FHS, the distribution or third-party packages must not touch them. As such, you should read the FHS to know what paths may be used by compliant software (the table of contents will tell you most of what you need to know).

For example, I personally use /av for where I store my audio-visual content, /src for source code and /data for undefined data (such as virtual machine images, cd images, chroots, saved packages, etc).

Answer 4

There is nothing wrong with creating a new mount point or directory for this purpose from the root.

Particularly if this is the primary purpose of this system, I would just create

/movies-enthusiast

If there are other similar "groups", I may or may not prefer to host them together, eg

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

or

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

Questions to consider: Are you going to dedicate a mount-point for this purpose?

Have you considered softlinks?

In any case there are no rules. If you want to make one user the custodian and give the rest access to this project space, feel free to host it in the user's home directory. Or create a /home/shared/* name-space. You are your own boss.

Oh, one thing: Whatever you do, do document it. It needs to become part of system recovery, daily checks, backups, etc. Important configuration detains need to be noted (eg group memberships, permission sets, fs tunables for performance, and anything else that is not a default)

Answer 5

It is important to remember that the FHS addresses issues where file placements need to be coordinated between multiple parties such as local sites, distributions, applications, documentation, etc; the FHS doesn't try to set rules for every single situation you may have: local placement of local files is a local issue (FHS 3.0, section 1.1).

Therefore, you may technically put your movies directory anywhere, as long as it doesn't go against FHS conventions. Still, your question was about the most appropriate place, so let's consider a few common answers (ordered from by most preferred to my less preferred, given your specific use case):

• /<someprefix>/<groupname> or /media/<volumename>/<groupname>: I honestly don't know why this option has a bad reputation in the Linux world, but let's make this clear: this is really your system, and the FHS says that you are free from creating new directories at the root level as long as you do not conflict with anything for which there is well-established semantics. You could for example create a directory /groups or /shared and organize files in these as you see fit. I know that some administrators prefer to have these somewhat isolated from the rest of the filesystem, so they mount a distinct volume (ie. under /media/<volumename>/<groupname>). Both are fine and both are FHS complient, really.

• /srv/<groupname> or /srv/<someprefix>/<groupname>: According to the FHS, /srv contains site-specific data which is served by this system. The FHS then goes on explaining that the methodology used to name subdirectories of /srv is unspecified. From my personal experience, most administrators that exploit the /srv directory goes on with a per-client, per-site or per-project subdirectory, and then put data directories at that level. However you structure it, the /srv is perfectly acceptable to store files to be shared among several users if you can reasonably consider that sharing these files constitute a service by itself. Ask yourself: "Would it make sense to eventually share those files through SMB/NFS/AFS/GIT/...?" If so, then you can reasonably consider that your directory is a local file sharing service, and thus store these inside a subdirectory of /srv, even though there is not a daemon actually serving those files to other systems.

• /home/<groupname> or /home/<some-prefix>/<groupname>: The FHS says: /home is a fairly standard concept, but it is clearly a site-specific filesystem. There is absolutely no requirement that every directory under /home be the name of an actual user, and it is acceptable to have subdirectories for groups, though precaution is required to avoid eventual conflicts between a group and a user. Still, I have seen this strategy in used in several large setups (notably universities) with some compartimentation strategy to avoid the possibility of conflict; for example, real users would have their home directories in /home/students/<studentid>, /home/teachers/<username> or /home/staff/<username>, while shared stuff would for example be put in /home/workgroup/<workgroupname>. Sometime they would also be a department subdivision; still, you get the idea. To be honest, I personally don't like this strategy, but it makes things a little bit easier when /home is distributed among several servers (for example via NFS), which is why it tends to be preferred in very large organizations.

Answer 6

FHS is also to make admin easy so I would go with /srv for that reason though its not what I have done. Have perfect hindsight though. I use /export/srv because its on NAS.

If its a drop box then make sure that it is both setgid and sticky. Also ensure that those using it have a useful umask. However, don't use wheel as I have done in the example of file access modes. Don't strip eXecute or you will be in for a O_o surprise.

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

Answer 7

I'd personally opt for /usr/share/movies-enthusiast or /opt/movies-enthusiast

Answer 8

I suggest to create a separate directory like /opt/movies , set appropriate user and group permissions for them and also you can use disk quota to avoid total disk consume..

Answer 9

This is as much a comment as an answer (so please don't downvote me for it!), but it's way too long to fit in a comment.

I do two things, both of which avoid the issue you're facing.

1) I make a separate partition of all the free space on my system disk and label it dataspace. That's where all my current media files and other data go. It gets automounted as /media/dataspace and I put anything that's "data" under a directory called "data" to separate it from things like work files, vms, or iso images that I don't want to routinely backup.

Using a separate partition has the added benefit that, if it fills up, it doesn't compromise my system like it would if it were stored under / or /home.

2) I put most of my data/media, especially things I'm not using "right now", on another physical drive (USB in my case with a notebook). That makes it easy to backup and easy to attach to another computer, should the need arise.