1

I have a folder /mnt/disk/folder.

  1. I want user1 and user2 to both have full recursive read+write access to any current and future directories and files.

  2. 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.

Improve this question

1 Answer 1

Reset to default
2

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!

Improve this answer
6
  • Thanks for this! I still get permission errors, though. Commented Oct 27, 2019 at 19:34
  • 1
    Would you mind updating the description of the problem with information about how the permissions are wrong? It would be interesting to see the sequence of commands : > test.txt followed by ls -lah and possibly also stat . and stat test.txt? Commented Oct 27, 2019 at 19:42
  • I have now updated the problem description. Commented Oct 27, 2019 at 21:34
  • 1
    Thank you very much. I am still not exactly sure in what mode it fails. So from only the users' point of view it works already, but it does not work when accessing the files through the server? What permissions does the server set on the files? (e.g. an ls -l output for a file created by the server would be interesting). Additoinally, what user does the server run under? What umask is active for the server process? Commented Oct 27, 2019 at 22:31
  • 1
    Yes, it certainly does. Running servers as root is generally considered bad practice. I would suggest creating a user called dataaccess (just like the group) and make that user's primary group the dataaccess group which already exists. Then run the server under that user (with umask 0002) such that all files created by the server running under that user are accessible Commented Oct 28, 2019 at 14:07

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.