docker-stacks
docker-stacks copied to clipboard
Permission denied when mounting folder with changed user
What docker image you are using?
jupyter/datascience-notebook
What complete docker command do you run to launch the container (omitting sensitive values)? I'm starting docker (Docker for Windows) from windows with the following batch script:
SET username=otheruser
SET currentfolder=%cd%
docker run %= Run docker with the following options =%^
--interactive %= Keep STDIN open even if not attached =%^
--tty %= Allocate a pseudo-TTY =%^
--rm %= Automatically remove the container when it exits =%^
-p 8888:8888 %= Publish a container's port(s) to the host =%^
--user root %= Username or UID (format <name|uid>[<group|gid>]) =%^
-e NB_USER=%username% %= Change user to the name specified in variable username =%^
-w /home/%username%/work %= Set starting folder =%^
-v %currentfolder%:/home/%username%/work %= Mount the folder the batch script is run in to the work folder of the selected user =%^
jupyter/datascience-notebook %= The script to start when the container starts =%^
start-notebook.sh %= Keep STDIN open even if not attached =%
What steps do you take once the container is running to reproduce the issue? The start script fails. Therefore, I do not take additional steps.
What do you expect to happen? I expect the jupyter notebook to start and to see the contents of the folder, the batch script is run within.
What actually happens?
I get the following error:
PermissionError: [Errno 13] Permission denied: '/home/otheruser/.local'
When I set the variable "username" in the batch script to "jovyan", the container starts as expected.
This part of the doc might hold a clue:
-v /some/host/folder/for/work:/home/jovyan/work- Mounts a host machine directory as folder in the container. Useful when you want to preserve notebooks and other work even after the container is destroyed. You must grant the within-container notebook user or group (NB_UID or NB_GID) write access to the host directory (e.g., sudo chown 1000 /some/host/folder/for/work).
from https://jupyter-docker-stacks.readthedocs.io/en/latest/using/common.html . Does otheruser own the file on the host and is NB_UID and/or NB_GID being set appropriately to match?
No, neither 'jovyan' nor 'otheruser' own the file on the host. And with username set to 'jovyan', no error occurs. Also, since the host folder is mounted to guest folder 'work', this does not seem to be the cause of the problem. The error message says that '.local' cannot be accessed, which should be located in the guest file system.
I think the problem is caused by mapping external volume on first run using a non existing username.
If I run:
$ docker run -it --rm --user root -e NB_UID=1234 -e NB_GID=1234 -e NB_USER=username -e NB_GROUP=groupname jupyter/base-notebook start.sh
Set username to: username
Relocating home dir to /home/username
Setting CWD to /home/username/
Set username UID to: 1234
Add username to group: 1234
Executing the command: bash
username@9dbfc95b69ae:~$ pwd
/home/username
username@9dbfc95b69ae:~$ ls -la
total 48
drwsrwsr-x 8 username groupname 4096 Jul 4 09:05 .
drwxr-xr-x 1 root root 4096 Jul 8 13:03 ..
-rw-rw-r-- 1 username groupname 220 Apr 4 2018 .bash_logout
-rw-rw-r-- 1 username groupname 3770 Mar 14 02:54 .bashrc
drwsrwsr-x 2 username groupname 4096 Jul 4 09:05 .cache
drwsrwsr-x 2 username groupname 4096 Jul 4 08:55 .conda
drwsrws--- 3 username groupname 4096 Jul 4 09:02 .config
drwsrws--- 2 username groupname 4096 Jul 4 09:05 .jupyter
-rw-rw-r-- 1 username groupname 807 Apr 4 2018 .profile
drwsrwsr-x 2 username groupname 4096 Apr 8 23:37 work
drwsrwsr-x 3 username groupname 4096 Jul 4 09:04 .yarn
username@9dbfc95b69ae:~$
but if I run:
$ docker run -it --rm --user root -e NB_UID=1234 -e NB_GID=1234 -e NB_USER=username -e NB_GROUP=groupname -v `pwd`/test:/home/username/work jupyter/base-notebook start.sh
Set username to: username
Setting CWD to /home/username/
Set username UID to: 1234
Add username to group: 1234
Executing the command: bash
username@3bce498aebda:~$ pwd
/home/username
username@3bce498aebda:~$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Jul 8 13:10 .
drwxr-xr-x 1 root root 4096 Jul 8 13:10 ..
drwxr-xr-x 2 1001 1001 4096 Jul 8 12:52 work
username@3bce498aebda:~$
So, looks like, when creating the new user's home directory if the home directory does not exists (as It was not externally mapped) the home directory is created with default files and permissions; but when the home directory exists (as It was created cause the external volume mapping -done by the root user-) then no default user files are created and directory permissions are not changed.
The only solution I found (without changing base images) is to create the container without the mapping (and without --rm), stop it, and re-run with the mapping (without --rm).
I experienced similar results as mentioned in @rubensa's post. I found that adding the following flags (as mentioned in the docs under NB_USER) partially resolved the missing files problem in /home/username: -e NB_USER=... -e CHOWN_HOME=yes -w .... The results:
Expected
- the original
/home/jovyanis renamed to/home/username - a
/home/jovyan/workdirectory is made and the external folder is mapped to it with the proper user permissions
Unexpected
/home/jovyan/workis symlinked to mysterious/home/username/jovyan/workfolders- These folders have the
username:userspermissions - An empty
/home/username/workfolder is there (supposedly remnants from the original home directory)
Critical
- Creating the volume with the
-vflag in this manner deletes any contents from the external folder.
I would like to mount an existing external folder (with contents) to some internal folder with the right permissions. It there a way to safely volume mount external folders? I would not like to mistakenly volume mount to a host folder, start up the container and lose data.
@jp68138743541 Can you please confirm that this is still an issue? It works fine me. Thx
Closing this one. Please reopen, if you still see this issue.