23

We are currently building a jupyterhub environment in a docker container and struggling with shared folders. Our goal is to set up a shared folder which is writable for all users.

In each user's home folder there is a symbolic link ~/shared to /opt/shared. The target folder has the permissions 777 and is owned by the group jupyter. Each user is member of the group jupyter. However, if one user creates a file in the shared folder logged in with his account into the web app, the permissions are set to 644. Therefore, no other user can edit the file.

I've tried to set the umask to 000 in the /etc/profiles and the ~/.bashrc files for each user. However, jupyter seems to ignore it. Is there a possibility to configure jupyter to create new files with g+w rights as default? I would like to avoid setting up access control lists with setfacl at the file system level because it requires custom flags in the /etc/fstab.

Jason Aller
  • 3,541
  • 28
  • 38
  • 38
Rudi
  • 311
  • 3
  • 8
  • 1
    Great question! Did you manage to solve it? What happens if two different users would try to edit the same file at the same time? – Dror Nov 16 '16 at 07:11
  • Do you have a programatic way to add all newly created jupyterhub users to the same UNIX group? I'm failing to find this prerequisite that you brought – steps May 06 '20 at 09:22

1 Answers1

12
  1. Set a group (i.e., jupyter in your case) to shared folder chgrp jupyter /opt/shared
  2. Allow the group to write to that directory + make group sticky (new files are created with this group instead of user's primary group) chmod g+ws /opt/shared
  3. For each user create ~/.jupyter/jupyter_notebook_config.py

With following content:

  import os
  os.umask(0o002)

Newly created files will be writable by the group.

Marian Schubert
  • 176
  • 1
  • 6
  • 3
    If you don't want to create a config file for each user, you create/use `/etc/jupyter/jupyter_notebook_config.py`, which applies to all Jupyterhub users. – J.T Feb 19 '18 at 19:33
  • This works, but it should be `os.umask(0x002)` - that is, an 'x' rather than an 'o'. – Enfors Dec 17 '18 at 20:30
  • 7
    @Enfors: No, umasks are usually given in octal, not in hexadecimal. It doesn't matter for the value in question (0o002 and 0x002 are both just 2), but it will matter when you try to set 0x022 instead of 0o022. – Pascal Feb 14 '19 at 02:35