What is the correct way to share data between users on a single machine?
I need to reinstall our home desktop. Currently, I simply grant group read/write access to the folders in my home directory that contains our photos, videos and music.
However, I often forget chmod -R g+rw when I download new photos from the camera. Similarly, my wife usually downloads the videos from the camcorder and is oblivious of linux access rights anyway. She might also access the data from Windows. (I installed a Windows EXT2/3-Driver). So since the data belongs to both of us, somewhere inside my home directory seems the wrong place, but where else then?
**
Where is the correct place inside the directory tree to place a hierarchy of shared data?
How do I ensure that the group read/write rights (and “executable” for directories) are automatically set for new data?**
I am sorry, but that does not give an answer to his question. When you use a seperate partition, the question is: where do you mount it?
I am curious to the answers others may give. I installed an extra user. So I have henk (that is me), marian (that is my wife) and wij (that translates into we). All members of the same group. And the common data are in the home dir. of wij.
Data there must have acess for the group and we both can work with it. As long as your umask is 770 (or 775, or what you like for the world bits) that is OK. One can also let root run a *cron *run (every 5 mins or so) to *chmod *there (remind that *wij *is almost never the owner, but *henk *or *marian *is, so *wij *can not do this).
As a pro I can mention that as everything is in /home (which is a seperate partition) system reinstalls automaticaly leave this data untouched as in the other home directories.
As a Con I think it is a bit artificial (but it works for us).
why the cron job for chown? I would assume that a directory with 770 is sufficient if both users are in the same group.
If you want to add some protection, you can use the sticky bit. http://www.linuxdevcenter.com/pub/a/linux/lpt/22_06.html
@buckesfeld. By “also” I just ment to offer a possibility. I also must stress that the right umask is not enough. The umask only allows bits to be set when a file is generated. The generating program suggests what bits it wants to set and umask may remove some, but will not add. So when a program asks the kernel to make a file with bits 720 and the umask is 775 it nevertheless will be 720. So a cron job may be handy here.
@STurtle. As a suggestion to make navigation to those directories/files more esay for the users you can let them make links from appropriate places within there /home/<user> tree to the /home/wij tree. So *henk *, to keep to my example, could do
cd ~/music
ln -s /home/wij/music shared-music
cd ~/Documents/Letters
ln -s /home/wij/letters our-letters
and using your file manager you can then navigate to those places where you expect to find music, letters, etc. Every user can do this for himself as he likes of course.
BTW when everything is in one and the same file system, hard links instead of symbolic could be made. I leave it to you to think about the PROs and CONs.
That is similar to what I previously tried: I created a directory in home, e.g. /home/shared, exactly because /home is a separate partition - and the one that gets backed up.
However, there was always the trouble with the permission to be to restrictive. I do not want sticky, as we both may move files around.
So I need a cron job for that yes? That sounds complicated. :\ Maybe I just create a FAT32 partition then - I hoped to get rid of all those.
Hmm, I thought that this would be a common problem with a common solution…
EDIT:@hcvv: Yes, I am aware of and use symbolic and hard links as appropriate. That was not the problem. I just wanted to know whether there is a canonical (default) directory for shared data like this, as I assumed this to be a common issue. The restrictive rights are a pain though - and I never dealt with “cron jobs”.
I do not see what a FAT32 could help here. It is about persmissions.
And the crontab is not that much of a problem. Open a console/terminal as root and type
crontab -e
You will see then a vi of your crontab (most possibly containing nothing). Type (the small letter) i (somewhere at the bottom it will show you are now in INSERT mode) and insert a line like
*/5 * * * * chmod -R ug+w /home/wij/
When the line is there hit the Esc key (the INSERT vanishes). Now type
:wq
and hit return. Done you are.
It will run:
every hour
/5 every 5 minutes
every day of the month
every month of the year
evry day f the week
in other words every 5 minutes (when the system is up )
Inheriting group permissions is a perennial problem.
You might want to look into using Posix ACLs (Access Control Lists) to solve it instead of a cron job, which always entails a certain amount of delay. (“Wait for a few minutes, dear.”) ACLs are supported by many Linux filesystems, including ext3. In fact I believe it was implemented by a SUSE employee.
There is a facility to make a directory require that any children inherit its default ACL. So you could make a directory writable by the group and require that its children be too.
You also have to mount the partition with ACLs enabled (option acl).
The man pages to read are acl, setfacl and mount. It should be possible to do it with a chgrp and a setfacl on the top directory.
Incidentally ACLs are also supported in Mac OS/X and they have a GUI to manipulate permissions, which isn’t the most intuitive, to be honest.
My thought was essentially the same as @ken_yap. Create a mount point, e.g., /home/shared. Give it group permission for “users”, read/write (you can do this in the file manager). In fstab just use “acl,user_xattr” in the mount options section. Files added to that directory will inherit the permissions set at the parent level.
Group working without acl’s or xattr’s is possible, by using a group to share access (users can belong to multiple groups).
chmod g+s /group/data/dir
Makes the files inherit the group from the directory with SysV semantics (in BSD it was assumed as a sensible default).
That generally suffices with a umask of 0002, because apart from security related files, programs ought to create files with permissive permissions ie creat( “foo.bar” , 666), so umask can operate correctly.
In general I have with large numbers of users, needed to “preen” permissions only daily, where folk could set them incorrectly working in private first. But then you should use find(1) to generate a list of files with wrong permissions or wrong group, -print0 | xargs -0 chmod 664.
The recursive chmod suggestions posted would update all the inodes in the directory tree, and alter the ctime stamps, which is undesirable as well as undesirable due to the uncessary i/o. I just checked this is still the case with “ls -lc” after “chmod g+r” on a file which appeared to be a null op.
The fly in the ointment is the umask. You have to get all the users to cooperate by allow group write in the umask. It also fails to allow group write when users copy in files from elsewhere where the group write is turned off. With ACLs you can set a top level directory ACL that permits group write and this will then propagate downwards.
Seems to suffice to ensure that all users belonging to group “users” will always have read/write access to all files in shared_dir and contained folders. I copy something in, and it receives the right permissions immediately!
When I do a dual boot system for someone, I always leave the shared directory as a windows directory, and then I edit my fstab so it mounts as /Shared. Then I just create links from the desktops of both OS’s. I find this the easiest, but there are lots of things that will work, and I’ve never done it with suse, so I can’t really be sure it would be the same, but I think so. I don’t think that there is a default place for these shared files to be in the linux file system, but if there is, I too would like to know where it is. I notice nobody answered that one for you. Let us all know what solution you went for and how you got there. It is good info to share.
Traditionally additional data partitions are mounted to a mount point under /mnt, e.g., /mnt/data. The SuSE installer now creates a new root sub-directory named /windows under which it puts a mount point for each Windows partition, e.g., /windows/c, etc. Something to keep in mind is that the linux ntfs driver does not write to the file system journal.
Only the owner of the directory can create new files inside now. Despite ls showing rwx for all, i.e. user, group and others, my wife cannot create files in directories that were created by me. chown fixed that for now, until I touch our shared data (Fotos, Homevideos, etc.) again.
I am giving up now. FAT seems indeed to be the easiest solution. :\
In Yast - Users and Groups - you can define the standard. Set it to 775 for every user. This will make created folders rw-accessible for other users.
BTW doing something like this via cron is just not the way. Next thing is that you let cron remove permissions for guests. Cron is for returning jobs, not for permission control
I do not see how this is a related answer, for **chmode -R a+rwx *** did not fix the problem! Only changing ownership did.
I guess this is due to trying to use the ACL, which now gives me drwxrwsrwx+ which is somehow weird.
BTW doing something like this via cron is just not the way. Next thing is that you let cron remove permissions for guests. Cron is for returning jobs, not for permission control
Yes, I agree. Thus I have not even tried the cron-job solution proposed yet. (Though it actually has more to do with me fearing to mess with cron configuration than anything else.)
A cursory reading of man 5 acl suggests you only get the inheritance of permissions from the containing directory if you modify the default ACLs, which you have to specify in the command.
)
No, it was not that simple, as it turned out now.