Docker-stacks: Permission denied when mounting local folders

Created on 17 Jun 2019  Â·  15Comments  Â·  Source: jupyter/docker-stacks

What docker image you are using?

Example: jupyter/all-spark-notebook

What complete docker command do you run to launch the container (omitting sensitive values)?
docker run -it --rm -p 8888:8888 -v /home/eduardo/Descargas/DockerSpark/:/home/jovyan/work -w /home/jovyan/work jupyter/all-spark-notebook

What steps do you take once the container is running to reproduce the issue?
Permission denied when mounting local folders. I tried everything related to files: upload a file from filesystem, save a notebook, access a dataset in the same folder and i cant...

Example:

  1. http://(869fbf0e4bbe or 127.0.0.1):8888/?token=d5f852e4322a7daccd8cc380d6199d2a3d071789d7ef9b60

imagen

What do you expect to happen?

Access files

What actually happens?
Error permission denied

Im using Ubuntu 18.04 LtS

eduardo@MiPcLinux:~/Descargas/DockerSpark$ docker version
Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.4
 Git commit:        e68fc7a
 Built:             Tue May  7 17:57:34 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.4
  Git commit:       e68fc7a
  Built:            Tue May  7 17:57:34 2019
  OS/Arch:          linux/amd64
  Experimental:     false

Than ks in advance

Question

Most helpful comment

Browsing the web, this seems like a very common issue. Most likely it is because the third example on the docs homepage specifies using -v without dealing with any of the permissions issues.

If that example doesn't work for most people out of the box, and the root user workarounds are not ideal for many people, should the example be removed?

All 15 comments

Any help ??

Hey @ejgutierrez74,
Not sure if you managed to solve your issue, but I was having the same.

After reading the docs (https://jupyter-docker-stacks.readthedocs.io/en/latest/using/common.html) I was able to get it running with the following env options:

docker run --rm -p 8888:8888 --name jupyter -e NB_USER=felipebn -e CHOWN_HOME=yes -e CHOWN_EXTRA_OPTS='-R' --user root -w /home/felipebn/ -v "C:\Users\felipe.brandao\eclipse-workspace-2019-01\Project\jupyter":/home/felipebn/ jupyter/base-notebook 

Important parts are:

  • NB_USER: set to whatver username you want, but be aware to reuse it
  • CHOWN_HOME and CHOWN_EXTRA_OPTS to give appropriate permissions
  • --user root: requried to make these changes
  • -w /home/felipebn/: to set the working dir for the notebook (use whatever username you used in the NB_USER env var)

edit: removed the "work" ending as it would be set to root

The note associated with the -v flag under https://jupyter-docker-stacks.readthedocs.io/en/latest/using/common.html#docker-options likely explains what needs to be done to allow the within container notebook process access to your host mounted home directory.

Hello

I've had same problem. But that flags (-e NB_USER=vmasip -e CHOWN_HOME=yes -e CHOWN_EXTRA_OPTS='-R' --user root -w /home/vmasip/ ) collapse container, it cannot start:

Set username to: vmasip
Changing ownership of /home/vmasip to 1000:100 with options ''
Executing the command: jupyter lab --NotebookApp.password=********
[I 08:54:05.232 LabApp] [nb_conda_kernels] enabled, 2 kernels found
Traceback (most recent call last):
  File "/opt/conda/lib/python3.7/site-packages/traitlets/traitlets.py", line 528, in get
    value = obj._trait_values[self.name]
KeyError: 'runtime_dir'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/conda/bin/jupyter-lab", line 11, in <module>
    sys.exit(main())
  File "/opt/conda/lib/python3.7/site-packages/jupyter_core/application.py", line 266, in launch_instance
    return super(JupyterApp, cls).launch_instance(argv=argv, **kwargs)
  File "/opt/conda/lib/python3.7/site-packages/traitlets/config/application.py", line 657, in launch_instance
    app.initialize(argv)
  File "</opt/conda/lib/python3.7/site-packages/decorator.py:decorator-gen-7>", line 2, in initialize
  File "/opt/conda/lib/python3.7/site-packages/traitlets/config/application.py", line 87, in catch_config_error
    return method(app, *args, **kwargs)
  File "/opt/conda/lib/python3.7/site-packages/notebook/notebookapp.py", line 1676, in initialize
    self.init_configurables()
  File "/opt/conda/lib/python3.7/site-packages/notebook/notebookapp.py", line 1349, in init_configurables
    connection_dir=self.runtime_dir,
  File "/opt/conda/lib/python3.7/site-packages/traitlets/traitlets.py", line 556, in __get__
    return self.get(obj, cls)
  File "/opt/conda/lib/python3.7/site-packages/traitlets/traitlets.py", line 535, in get
    value = self._validate(obj, dynamic_default())
  File "/opt/conda/lib/python3.7/site-packages/jupyter_core/application.py", line 99, in _runtime_dir_default
    ensure_dir_exists(rd, mode=0o700)
  File "/opt/conda/lib/python3.7/site-packages/jupyter_core/utils/__init__.py", line 13, in ensure_dir_exists
    os.makedirs(path, mode=mode)
  File "/opt/conda/lib/python3.7/os.py", line 211, in makedirs
    makedirs(head, exist_ok=exist_ok)
  File "/opt/conda/lib/python3.7/os.py", line 211, in makedirs
    makedirs(head, exist_ok=exist_ok)
  File "/opt/conda/lib/python3.7/os.py", line 211, in makedirs
    makedirs(head, exist_ok=exist_ok)
  File "/opt/conda/lib/python3.7/os.py", line 221, in makedirs
    mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: '/home/vmasip/.local'


Besides that, it makes (as documentation specifies) mounted drive folder change its permissions to root. I don't like this.
If I try to use the "silver bullet" of docker user and group options, it doesn't work because user and group must be specified in the Dockerfiles.

My solution:
I didn't like this from log:
Changing ownership of /home/vmasip to 1000:100 with options ''
Because (in my computer) user vmasip GID is 1000. Then I used this:
-e NB_GID=1000
Finally, log shows now:

Set username to: vmasip
Changing ownership of /home/vmasip to 1000:1000 with options ''
Add vmasip to group: 1000

Now it works, and my _vmasip_ user in container belongs to users and vmasip groups (1000).

Browsing the web, this seems like a very common issue. Most likely it is because the third example on the docs homepage specifies using -v without dealing with any of the permissions issues.

If that example doesn't work for most people out of the box, and the root user workarounds are not ideal for many people, should the example be removed?

Hey @ejgutierrez74,
Not sure if you managed to solve your issue, but I was having the same.

After reading the docs (https://jupyter-docker-stacks.readthedocs.io/en/latest/using/common.html) I was able to get it running with the following env options:

docker run --rm -p 8888:8888 --name jupyter -e NB_USER=felipebn -e CHOWN_HOME=yes -e CHOWN_EXTRA_OPTS='-R' --user root -w /home/felipebn/ -v "C:\Users\felipe.brandao\eclipse-workspace-2019-01\Project\jupyter":/home/felipebn/ jupyter/base-notebook 

Important parts are:

* NB_USER: set to whatver username you want, but be aware to reuse it

* CHOWN_HOME and CHOWN_EXTRA_OPTS to give appropriate permissions

* `--user root`: requried to make these changes

* `-w /home/felipebn/`: to set the working dir for the notebook (use whatever username you used in the NB_USER env var)

edit: removed the "work" ending as it would be set to root

This is working for me. Thanks!

This seem to have worked out of the box until the tag 9e8682c9ea54 and caused issues afterwards.

The above instructions don't seem to exactly work, it may have changed.

Now one should set CHOWN_HOME_OPTS instead of CHOWN_EXTRA_OPTS. The latter works in conjunction with CHOWN_EXTRA.

Related code: https://github.com/jupyter/docker-stacks/blob/56e54a7320c3b002b8b136ba288784d3d2f4a937/base-notebook/start.sh#L52-L61

seem to have worked out of the box until the tag 9e8682c9ea54 and caused issues afterwards.

The above instructions don't seem to exactly work, it may have changed.

Now one should set CHOWN_HOME_OPTS instead of CHOWN_EXTRA_OPTS. The latter works in conjunction with CHOWN_EXTRA.

Yes, I used same options, but when I try to translate them to docker-compose, it doesn't work. I have to comment three lines because, even with no errors, and same jupyter log, volume is not available in folder navigation if a complete docker-compose with _docker run_ options:

version: "2"

services:
  notebook:
    build: ../minimal-notebook
    image: jupyter/minimal-notebook
    container_name: ${NAME}
    volumes:
     - "work:/home/jovyan/work"
     - "secrets:/etc/secrets"
    ports:
      - "${PORT}:8888"
    user: root  
    working_dir: /home/jovyan/work
    environment:
      JUPYTER_ENABLE_LAB: 1 
      #NB_USER: ${USER}
      NB_GID: 1000
      #CHOWN_HOME: 'yes'
      #CHOWN_HOME_OPTS: '-R'
      --NotebookApp.password='sha1:*-*-*-'

volumes:
  work:
    external:
      name: ${WORK_VOLUME}
  secrets:
    external:
      name: ${SECRETS_VOLUME}

If I leave uncommented lines, it doesn't work. So I have to work as jovyan.

Any solution?

Hello,

I will have a look at it to clarify this problem that seems recurrent see #1003.
We added a test, however it seems to not be sufficient.

https://github.com/jupyter/docker-stacks/blob/619e9cc2fc073bd59697c1fababfa0ca326044f6/base-notebook/test/test_container_options.py#L81-L92

I keep you informed.
Best.

Hello @masip85

Here is a quote from the documentation

  • -e NB_USER=jovyan - Instructs the startup script to change the default container username from jovyan to the provided value. Causes the script to rename the jovyan user home folder. For this option to take effect, you must run the container with --user root and set the working directory -w /home/$NB_USER. This feature is useful when mounting host volumes with specific home folder.

There is an inconsistency in your docker-compose.yml file.

    volumes:
     - "work:/home/jovyan/work"
     - "secrets:/etc/secrets"
    ports:
      - "${PORT}:8888"
    user: root  
    working_dir: /home/jovyan/work
    environment:
      JUPYTER_ENABLE_LAB: 1 
      NB_USER: ${USER}
      NB_GID: 1000
      CHOWN_HOME: 'yes'
      CHOWN_HOME_OPTS: '-R'

You mount the volume in the container to /home/jovyan/work you set the working dir to /home/jovyan/work but by changing the NB_USER the start.sh script will change the user's home to /home/$USER/work.

To switch to a custom user you have to set it in the working_dir and also in the volumes.

    volumes:
-     - "work:/home/jovyan/work"
+     - "work:/home/${USER}/work"
     - "secrets:/etc/secrets"
    ports:
      - "${PORT}:8888"
    user: root  
-    working_dir: /home/jovyan/work
+    working_dir: /home/${USER}/work
    environment:
      JUPYTER_ENABLE_LAB: 1 
      NB_USER: ${USER}
      NB_GID: 1000
      CHOWN_HOME: 'yes'
      CHOWN_HOME_OPTS: '-R'

:warning:Please make sure to make a backup of the content of your volume before performing this change in order to avoid any accidental loss of data:warning:.

Note: I will check to improve the tests if needed to handle this case.

Please give us your feedback.
Best

Ok,I made a bug that comes from not eliminating a volume,which didn't fit with new configs. After that,I changed to jovyan. But deleting volumes properly did the trick and now is working with my user.

And yes, this set of configurations can be dangerous, I realized -when I used same settings with docker run- and I changed owner of thousands of files by accident.

Let me add,to make this thing works with existing local folder, volume must be created like this:
docker volume create --name "$WORK_VOLUME" --opt type=none --opt device=/mnt/sda2/home/vmasip/Descargas --opt o=bind

Hello @masip85 ,

Thank you for your answer. Great to hear that it's OK for you now. For information I've created an issue (#1077) and proposed a PR to improve the documentation on using NB_USER to change the default user.

Best

I also had this same problem when mounting host folders for jupyter/datascience-notebook.
I was able to solve it by adding --user <UID> --group-add users options to docker run.
From the docs:

--user 5000 --group-add users - Launches the container with a specific user ID and adds that user to the users group so that it can modify files in the default home directory and /opt/conda. You can use these arguments as alternatives to setting $NB_UID and $NB_GID.

My environment:

  • Ubuntu 18.04.5 LTS
  • Docker version 20.10.5, build 55c4c88

The following is my docker run command:

#!/bin/bash
PORT=8888
DATA=/home/kent/hot_data
NOTEBOOKS=/home/kent/notebooks

docker run --rm \
  -p ${PORT}:8888 \
  -v "${DATA}":/home/jovyan/data \
  -v "${NOTEBOOKS}":/home/jovyan/work \
  --gpus 'all,capabilities=utility' \
  --user "$(id -u)" --group-add users \ # $(id -u) prints the UID of the user that called docker run
  jupyter/datascience-notebook

Hope this helps. It took me a whole day to solve this. Hopefully the team can update the examples and docs to make mounting host folders more clear.

Guys, it seems that the solution is simpler than you think.

This example is working for me (ubuntu):

docker run -it \
    -p 8888:8888 \
    -e JUPYTER_ENABLE_LAB=yes \
    -e CHOWN_HOME=yes \
    -e CHOWN_HOME_OPTS='-R' \
    -v $(pwd)/work:/home/jovyan/work \
    jupyter/minimal-notebook:4d9c9bd9ced0

The key to the victory is the option CHOWN_HOME:

Instructs the startup script to change the $NB_USER home directory owner and group to the current value of $NB_UID and $NB_GID. This change will take effect even if the user home directory is mounted from the host using -v as described below.

This configuration worked out for me:

notebook:
  build: ./notebook  # In this folder there's my Dockerfile
  ports:
    - 8900:8888
  environment:
    JUPYTER_ENABLE_LAB: 1
    NB_USER: jovyan
    NB_GID: 1000
    CHOWN_HOME: 'yes'
    CHOWN_HOME_OPTS: '-R'
  volumes:
    - type: volume
      source: notebook-data
      target: /home/jovyan/working-dir
      read_only: false

I strongly advise against setting -u root in docker run, or user: root in docker-compose. There's a reason why Jupyter doesn't get sudo privileges — it'd not ideal, from a security standpoint, to run Jupyter as root (being vulnerable to quite trivial command execution).

Was this page helpful?
0 / 5 - 0 ratings