Where on a Linux file system should someone put media intended to be accessible by all user accounts?

5

2

If I have photos, mp3s, books and other miscellaneous stuff that I want all users to able to access from a common directory, where on a Linux file system should I put that directory? In /usr/share, or just in /usr, or create a new top-level directory instead?

Brad

Posted 2009-12-29T08:16:32.600

Reputation:

Answers

8

I usually put this in /home/media, I create a media unix group that owns it with a setgid bit.

As root, or using sudo:

groupadd media
mkdir -p /home/media
chown -R root.media /home/media 
chmod g+s /home/media

Then I put each user that needs to access these data in the media group.

You could also use ACLs to manage each user's right for the directory.

You could also use /srv/media if you prefer, but I like home for shared documents. Anything in /usr is to be avoided for this unless you're talking about static files.

ℝaphink

Posted 2009-12-29T08:16:32.600

Reputation: 3 531

Why not add write permissions to the directory? At least on my machine (Ubuntu 15.10), the folder is given write permissions to the user that created it (which has to be root), but no one else. Speaking of that, you may want to specify you need su or sudo to execute all these commands. – trysis – 2016-06-03T02:07:59.683

1/srv is the place recommended by the FHS: "site-specific data which is served by this system." – TRS-80 – 2009-12-29T11:42:35.057

1or /opt or /some-madeup-term (my personal fave: /middleearth). /usr/local (or even /usr/local/shared) would be OK, but not ideal. i dislike /home for this purpose because /home is for user directories, and i consider data files outside the scope. on a true multiuser installation, tho, it's probably more appropriate. – quack quixote – 2009-12-29T11:49:26.010

1I agree with most of your comments. However, I don't agree with /usr/local, which is a subsection of /usr, which imo is dedicated to static, read-only data. /usr/local is more likely to contain locally compiled programs or administration scripts.

As for /srv, I listed it because it seems like the best place according to the FHS, but then it's for data "served by this system". To me, photos, mp3, etc on a desktop are more of user data, which belong to /home. They're not really "served" by the machine so to say. – ℝaphink – 2009-12-29T12:12:51.580

/usr/local/shared is not listed in the FHS, but there is /usr/local/share which is the local equivalent of /usr/share, which contains static files used by programs that do not belong in /usr/lib, so it's definitely not a good place for varying data such as user documents imo. – ℝaphink – 2009-12-29T12:14:35.147

share is what i meant, oops. it depends on the data and the usage -- on my home server, i handle most of the content generation, my user owns the files, but i want them accessible via network shares. putting everything under /middleearth (or /srv) allows me to create the Samba shares without letting Samba anywhere near my user's home directory. it's useful for my use case. in a multiuser system, you centralize the data for the same reason -- so you can give users 1, 2, & 3 access to the data without letting them into eachother's home directories. – quack quixote – 2009-12-29T12:20:37.387

3

I use /av - it's nice and short so it's easy to type.

FHS compliance is not an issue. FHS is a standard for your distribution and applications to follow. A distribution or application should never create a top-level directory, but as a user and system administrator, the filesystem namespace is yours to use as you wish.

Putting it in /home is a bad idea, as that directory is for home directories. Your shared media directory is not a home directory. Consider that if you use /home/media and later need to create a user called 'media'.

Similarly, avoid directories that are managed by your distribution. /usr/share/media is a bad idea, since a package in your distribution might well use that path.

/usr/local, /opt and /srv are defined places where you have control of the namespace underneath, but /opt is usually for application directories and /srv for data that the host is serving up. /usr/local/share may be appropriate, but that's just too long a path for my liking.

Above all, remember it's your filesystem so there's nothing wrong with creating a new top-level directory.

camh

Posted 2009-12-29T08:16:32.600

Reputation: 441

amen brothah man. as i mentioned earlier, i use /middleearth, as it's memorable, but i do symlink to /me for a handy shortcut. – quack quixote – 2009-12-30T02:17:53.207

2

<mode=pedant>
According to the Filesystem Hierarchy Standard, /usr is for "shareable, read-only data"; /usr/share is for "read-only architecture independent data files. ... for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted"

So yes, a subdirectory of /usr/share seems like an appropriate choice.
</mode>

<mode=pragmatist>

Less pedantically, /home (as suggested by raphink) seems like a good choice. You probably have /home on its own partition, both so that you can easily blow away the rest of the OS without touching user data (eg, when doing an upgrade or reinstall) and for ease of backup (as everything you care to back up is stored under /home), and for space management reasons (on most home boxes, the partition with /home ends up being the one that runs out of space first).

</mode>

James Polley

Posted 2009-12-29T08:16:32.600

Reputation: 5 892

I wouldn't consider photos and mp3s to be read-only files. I tend to edit my photos quite often ;-) – ℝaphink – 2009-12-29T10:38:15.980

And videos might have a habit of disappearing after they've been watched once or twice... and most media library programs (I'm thinking of iTunes, but f-spot does something similar, and I bet rhthymbox and songbird do as well) will have some kind of database with play count information and so on - and that definitely doesn't belong under /usr. /home seems like a sensible choice, even if it's not strictly FHS-compliant. – James Polley – 2009-12-29T12:20:11.553