Hi! Thanks for using Jupyter's docker-stacks images.
If you are requesting a library upgrade or addition in one of the existing images, please state the desired library name and version here and disregard the remaining sections.
If you are reporting an issue with one of the existing images, please answer the questions below to help us troubleshoot the problem. Please be as thorough as possible.
What docker image you are using?
jupyter/datascience-notebook
What complete docker command do you run to launch the container (omitting sensitive values)?
docker run -dit --name datascience --user root -e GRANT_SUDO=yes -e NB_UID=1000 -e NB_GID=1000 --restart always -p 80:8888 -v /vagrant:/home/jovyan/work start-notebook.sh --NotebookApp.notebook_dir=work --NotebookApp.token=''
What steps do you take once the container is running to reproduce the issue?
docker logs datascience
Set username to: jovyan
usermod: no changes
Set jovyan GID to: 1000
Granting jovyan sudo access
Executing the command: jupyter notebook --NotebookApp.notebook_dir=work --NotebookApp.token=
sudo: jupyter: command not found
Set username to: jovyan
usermod: no changes
Granting jovyan sudo access
What do you expect to happen?
see the jupyter notebook initialization logs
What actually happens?
the server does not start as the sudo user does not find jupyter
Regression due to #509. I need to add more integration tests clearly.
In the meantime, the workaround is to pin to the prior build tag, 0b3ec811c968.
Gah, right, forgot about secure_path in sudoers. We can either add /opt/conda/bin permanently as part of the build process or switch to full paths like /opt/conda/bin/jupyter-notebook if we don't want to trust things that might get installed in the container.
I have the same issue with docker run -ti --user=root -e NB_UID=1000 -e NB_GID=1000 jupyter/datascience-notebook
I think sed -ri "s#Defaults\s+secure_path=\"([^\"]+)\"#Defaults secure_path=\"\1:$CONDA_DIR/bin\"#" /etc/sudoers should have been added outside the GRANT_SUDO condition
Or the documentation should say that the GRANT_SUDO condition is necessary in that case, but I don't think that's the idea
Has this been resolved? I am still getting "sudo: jupyter: command not found" when running the latest
FROM jupyter/pyspark-notebook:latest
or
FROM jupyter/pyspark-notebook:400c69639ea5
using docker-compose
@Bidek56 The case noted in the original description should be resolved, but the one noted in @nbonnotte's comment still remains.
How do get around this issue?
jupyter/pyspark-notebook:latest still throws: "sudo: jupyter: command not found" when using docker-compose
Do I just add GRANT_SUDO=yes ?
jupyter/pyspark-notebook:27ba57364579 resolved the issue. Thanks!!
The error happens because the binary you are trying to call from command line is only part of the current user's PATH variable, but not a part of root user's PATH.
You can verify this by locating the path of the binary you are trying to access. In my case I was trying to call "bettercap-ng". So I ran,
$ which bettercap-ng
output: /home/user/work/bin/bettercap
I checked whether this location is part of my root user's PATH.
$ sudo env | grep ^PATH
output: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
So sudo cannot find the binary that I am trying to call from commandline. Hence returns the error command not found.
You can direct sudo to use the current user's PATH when calling a binary like below.
$ sudo -E env "PATH=$PATH" [command] [arguments]
In fact, one can make an alias out of it:
$ alias mysudo='sudo -E env "PATH=$PATH"'
It's also possible to name the alias itself sudo, replacing the original sudo.
Please refer to this video for step by step solution
@anandumdas thx for saving my ass
Most helpful comment
The error happens because the binary you are trying to call from command line is only part of the current user's PATH variable, but not a part of root user's PATH.
You can verify this by locating the path of the binary you are trying to access. In my case I was trying to call "bettercap-ng". So I ran,
$ which bettercap-ngoutput: /home/user/work/bin/bettercapI checked whether this location is part of my root user's PATH.
$ sudo env | grep ^PATHoutput:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/binSo sudo cannot find the binary that I am trying to call from commandline. Hence returns the error command not found.
You can direct sudo to use the current user's PATH when calling a binary like below.
$ sudo -E env "PATH=$PATH" [command] [arguments]In fact, one can make an alias out of it:
$ alias mysudo='sudo -E env "PATH=$PATH"'It's also possible to name the alias itself sudo, replacing the original sudo.
Please refer to this video for step by step solution