Linux – Set up a shared folder for users on a Linux server

linuxunix

I have a folder /mnt/disk/folder.

I want user1 and user2 to both have full recursive read+write access to any current and future directories and files.
I want to symlink the folder to /home/user1/data/ and /home/user2/data/ with access rights maintained.

This is what I have done:

Make the directory

mkdir /mnt/disk/folder

Symlink the to the directory

ln -s /mnt/disk/folder /home/user1/data
ln -s /mnt/disk/folder /home/user2/data

Make a group for sharing

sudo groupadd sharing

Add users to that group

sudo usermod -a -G sharing user1
sudo usermod -a -G sharing user2

Chown all existing files (not any in this case) to belong to the group

sudo chgrp -R sharing /mnt/disk/folder

Make all existing files (not any in this case) group-read-write

sudo chmod g+rw -R /mnt/disk/folder

Ensure that all newly created files and directories will belong to the group

chgrp sharing /mnt/disk/folder
chmod g+s /mnt/disk/folder

If logged in as user1 doing mkdir /home/user1/data/folder/123it works.
As does cd 123 and >test.txt.

If then logging in as user2 and navigating to /home/user1/data/folder/, the stuff created by user1 is there, and both users can create, edit, and remove directories and files.

I run a JupyterHub server, however, where user1 and user2 access their directories through jupyter's browser interface. When creating and editing here, permissions do NOT work.

Best Answer

Part 2: The Symlink

The second part is easy: Symlinks always maintain permissions in the sense that you would expect. Thus create them simply by ln -s:

ln -s /mnt/disk/folder /home/user1/data
ln -s /mnt/disk/folder /home/user2/data

(In case you are using applications which fail to work correctly with the symlink, consider using a bind mount).

Part 1: Correct access permissions

This is the "more tricky" part, because it depends (at least in part) on the cooperation of the users. The basic UNIX approach to this kind of problem is to make both users (user1 and user2) part of the same group (e.g. dataaccess). Then, all existing data needs to be chown'ed to belong to that group e.g. by means of a command like this:

chgrp -R dataaccess /mnt/disk/folder

Finally, all the files in the directory need to be group-read-write, which can e.g. be achieved by a chmod g+rw -R /mnt/disk/folder for the existing files.

Having established access to the existing files, the user cooperation comes into play: All newly created files and directories need to belong to the group and need to have the g+rw bits set. The correct setting of permissions can be achieved by configuring a suitable umask for both of the users.

The last step is to ensure that newly created files and directories belong to the correct group. This can be done manually by the users by invoking suitable chgrp commands after they created files or automated by means of the setgid bit, see this question: https://askubuntu.com/questions/51951/set-default-group-for-user-when-they-create-new-files.

If you cannot rely on the users to create files which only they have access to, you could establish an automated permission-widening mechanism by means of a cronjob or inotify.

Another "sledgehammer approach" which comes with a lot of problematic side-effects is the use of a filesystem which does not support permissions and will thus always have (mount-time-configurable) access permissions. FAT32 comes to mind, but it is highly recommendable to use the cleaner solution outlined before instead!

Related Solutions

Linux – How to Set Up a Shared Directory

What you have actually looks correct. You have the setgid bit set on the directory, so new files created should inherit the staff group. They do still remain owned by the creator, though. I suspect the problem is that the umask for your users is defaulting to 022 or even 077, which means new files they create will not have the group-write permission by default. The user/group ownership is correct, but the group permissions do not permit other members of the group to write (or maybe even read) the files.

Pick a user in the staff group and set the umask to 002 or 007, which means new files will be owner- and group-writable. I suspect this will correct the problem:

bash$ umask
0022
bash$ umask 002
bash$ umask
0002

Also, you noted you don't want anyone outside of the staff group to have any access to the directory at all. You should modify the directory permissions to 2770 to achieve this, otherwise non-staff will be able to read (but not modify) files in the directory.

For the last question about the apache user, the easiest way is probably to add that user to the staff group.

Linux – How to set the file permissions permanently for a directory in Linux

It sounds from your description that the cron job just needs to read the files, which it should be able to do. Is the issue that you're trying to uncompress the files in place? Can you uncompress them to a temporary folder instead?

In order to modify the permissions of new files uploaded by FTP, you would need to change the umask of the FTP daemon process to 002. How to do that depends on the FTP server and Linux distribution.