Common (?) use-case
September 15, 2006 10:06 am gnomeOur computer is primarily a home machine – there’s myself, my wife, and now my son who use the computer regularly.
We want to keep some information (documents, bookmarks, email, saved passwords) separate, but we want to share a certain number of resources (family photos, music) across all accounts.
Ideally in this use-case, if Anne imports photos from the camera’s memory card, I should have read/write access to the photos afterwards and they should automagically appear in f-spot. Likewise, if I import tracks from a CD into my rhythmbox repository, Anne would like to have those tracks appear automatically when she starts it up.
I know this is possible with some trickiness – I add all users on the machine to the same group, and set up /home/photos, /home/music and so on to have permissions ug+rwx with the gid bit set on the directories, and then set up symlinks to the relevant directories for each user so that things Just Work, but I imagine that this kind of usage (share some stuff, don’t share other stuff, in a small household) is something that comes up quite a lot – most people probably solve the problem by just having everyone use the same account, and storing documents in different directories.
Is there a better way to solve this problem in fspot/gthumb/rhythmbox/…? A preference to let someone point to a shared repository of music/photos?
September 15th, 2006 at 8:11 pm
Hi, nice to see a comment about that. I always have this problem and don’t really know how to solve it.
In Windows XP, you have the Shared Resources Folder, which you could imitate in Linux, but still, you have to set it up for everyone. But that’s similar to your approach.
So I’m also highly interested in a useful way.
September 15th, 2006 at 9:18 pm
This is a very important question and it does not only apply to home users. I simpler solution for sharing files between multiple users would be great. Having non technical users fiddle around with permissions is not a very good solution. The samba way where all files in a “share” inherit the permission and ownership of the “share” is a rather nice solution.
September 15th, 2006 at 9:47 pm
This is what I do for Rhythmbox. It can probably be modified for other applications as well.
First, create a directory for your multimedia, specifically your music. Based on my understanding of the Linux FHS, a reasonable place to store music is /usr/share/multimedia/music.
Now, decide what permissions you want to give to that directory. Me, I like to add everything myself. I have root access, so I can always add music to the shared music directory. I also don’t want others messing with my ID3 tags (or adding music with poor/no ID3 tags). That means that others really only need read access. I settled on the following:
shilo@shilo2:~$ ls -l /usr/share/multimedia/
total 30
drwxr-xr-x 885 shilo users 27344 2006-09-07 11:58 music/
You can use whatever ownership and permissions work for you.
Now everyone can listen to the shared music. Users will probably want to add their own music as well. For that, they will use ~/music.
Once you have that all squared away, it’s time to set up Rhythmbox. Just fire it up and use the “Music -> Import Folder…” option twice, once for /usr/share/multimedia/music and once for ~/music.
Now for the finishing touches. Open up “Edit -> Preferences…” and go to the “Library” tab. Under “Library Location” you enter /usr/share/multimedia/music (or ~/music if you prefer). If you like, you can also check the “Watch my libray for new files” option.
Close up Rhythmbox and fire up the gconf editor. Look under “Apps -> rhythmbox”. You will see “library_locations” and it will already be filled in with the one value that you gave it earlier. Double click that value and you will see that you can add additional directories to that value. Add the second value (~/music).
All set. One handy trick to know is that you can set up Automatic playlists based on “path contains /usr/share/multimedia/music” or “path contains ~/music”, if you are looking for that sort of thing.
So the only real question is what permissions you want to give to the shared directory. This is pretty much what you have outlined already, I know, but setting the shared directory to subs of /usr/share/multimedia seems to make more sense to me than adding a bunch of new directories under /home.
As a side note, I keep /usr/share/multimedia on a separate partition. This makes for easy upgrades. I also export /usr/share/multimedia via NFS to other computers on my LAN. Again, permissions are the only thing you need to worry about. You could also use SAMBA, if you want to share with Windows machines on the LAN. When exporting, I always export read-only, which keeps overzealous programs from other machines from trashing my data.
September 16th, 2006 at 1:43 am
Yes, this would be useful to have. I have the symlink thing set up and the permissions are always messed up. /usr/share is really just a dump for program data (whether “shared” or not), not users’ docs, but it’s not a bad place to put a “shareddocs” directory or someting; set the setgid bit and maybe sticky; then just make it a top-level place in Nautilus, alongside Home and Computer. So the place to implement this feature is in Nautilus, I think. Would the directory also need to be in a “users” group? Unfortunately what that group is called will vary from distribution to distribution. The other problem is that a user may somehow save a file there that does not get g+w, in that case maybe Nautilus could put up an unobstrusive query about setting it?
Maybe I’ll submit a feature request, any other comments?
Reed
September 16th, 2006 at 1:45 am
I guess it ought to also be addded to Gnome so that it shows up in Save and Open file dialogs too.
September 16th, 2006 at 2:28 am
ACLs help for the permissions bit, eiciel http://rofi.pinchito.com/eiciel/ is useful for that.
As far as discovery: ???
Avahi bookmarks used in nautilus and the file dialogs, maybe?
Symlinks are good too, but only for those who know about them.
September 16th, 2006 at 3:08 am
The question mark should definitely be removed. It is a common use-case. I have (not) “solved” it with a cron script that gives rw access to everything in the /home/everybody folder but was annoyed that the distro in question (in my case Ubuntu) didn’t address the issue. If somebody asked me about it, it would be pretty embarassing to answer: “Change groups, setup permissions etc.” instead of just saying “Right click on the folder and …”.
You get the idea…
Thanks for your post.
September 16th, 2006 at 3:21 am
Enrico: chmod -R g+s is your friend.
g+s ensures that all directories get created with the same GID as the parent. In combination with a same umask for this kind of machine (002), you should not need your cron job any more.
September 16th, 2006 at 9:15 am
An extension of this problem is when everyone has their own laptops, but you would like the data from everyone else’s music libraries/photo libraries to either automagically transfer to the one stable desktop computer with the big hard drive or to “broadcast” to all the other ones on your network.
Apple do this with iTunes sharing and bonjour. IMO this needs to be taken further…
September 16th, 2006 at 11:43 am
I solved this on my computer by setting the umask in /etc/profile to 007 or 002 (that’ll give the owner group RW access on newly created files). Then the setgid bit on the folder helps a lot, because now the shared group access just works (I make a point of making users with access to those shared resources be members of the shared group). Most apps work fine, but some… ugh… they suck at it, because some of them have their own idea of what the correct group should be.
Nowadays, default directory ACLs go a long way of giving you a more sophisticated and finely grained solution to this issue.
September 18th, 2006 at 8:37 pm
> if I import tracks from a CD into my rhythmbox repository,
> Anne would like to have those tracks appear automatically
> when she starts it up.
Sounds like a task for DAAP 🙂
September 29th, 2006 at 8:58 am
there is a tick box in rhythmbox to enable daap sharing. maybe it could also turn on a local sharing. there would be no need for daap to be used locally, but the interface could be identical (the other user’s music shows in the source list)