c.Spawner.notebook_dir does not have the expected effect

JupyterHub
1

I am running a JupyterHub setup where c.Spawner.notebook_dir is set to /srv/notebooks. Since upgrading to version 4.0.1 of the jupyterhub package, this does not have the expected effect anymore (however, I cannot exclude that the cause of this is something other than the upgrade). Instead of /srv/notebooks, the root directory in the single users’ interfaces is now their home directory. The JUPYTERHUB_ROOT_DIR environment variable of the jupyterhub process seems to be correctly set to /srv/notebooks. Does anyone have any idea what could be going wrong here?

2

Depending on your previous setup you might have switched from jupyter-notebook to jupyter-server which uses a different configuration file:
https://jupyter-server.readthedocs.io/en/latest/users/configuration.html

If that doesn’t help please provide us with full details of your JupyterHub setup such as how you deployed JupyterHub, your configuration, what exactly changed (old/new versions) during the upgrade, etc.

3

Thank you for the reply. I don’t think what you mentioned was the issue, but I am not sure. Putting a jupyter-server configuration file with c.ServerApp.root_dir = '/srv/notebooks' into the first directory listed by jupyter --paths did not have any effect.

Here are more details:

I am deploying JupyterHub using the jupyterhub command from a conda environment on a Debian virtual machine, and using an nginx reverse proxy.

My configuration contains two changes from the default configuration:

1011c1011
< # c.Spawner.default_url = ''
---
> c.Spawner.default_url = '/lab'
1139c1139
< # c.Spawner.notebook_dir = ''
---
> c.Spawner.notebook_dir = '/srv/notebooks'

The changes during the upgrade are the following (the update leading to my initial post contained more changes, but I could reproduce the issue updating just these two packages):

     jupyterhub  {3.1.1 (conda-forge/noarch) -> 4.0.1 (conda-forge/noarch)}
     jupyterhub-base  {3.1.1 (conda-forge/noarch) -> 4.0.1 (conda-forge/noarch)}

The unchanged versions other related packages are the following:

    +jupyter-dash-0.4.2 (conda-forge/noarch)
    +jupyter-lsp-2.1.0 (conda-forge/noarch)
    +jupyter_client-8.1.0 (conda-forge/noarch)
    +jupyter_core-5.3.0 (conda-forge/linux-64)
    +jupyter_events-0.6.3 (conda-forge/noarch)
    +jupyter_server-2.5.0 (conda-forge/noarch)
    +jupyter_server_fileid-0.8.0 (conda-forge/noarch)
    +jupyter_server_terminals-0.4.4 (conda-forge/noarch)
    +jupyter_server_ydoc-0.8.0 (conda-forge/noarch)
    +jupyter_telemetry-0.1.0 (conda-forge/noarch)
    +jupyter_ydoc-0.2.3 (conda-forge/noarch)
    ...
    +jupyterlab-4.0.2 (conda-forge/noarch)
    +jupyterlab_pygments-0.2.2 (conda-forge/noarch)
    +jupyterlab_server-2.21.0 (conda-forge/noarch)
    +jupyterlab_widgets-3.0.7 (conda-forge/noarch)
    ...
    +nbclassic-0.5.3 (conda-forge/noarch)
    +nbclient-0.7.2 (conda-forge/noarch)
    +nbconvert-7.2.9 (conda-forge/noarch)
    +nbconvert-core-7.2.9 (conda-forge/noarch)
    +nbconvert-pandoc-7.2.9 (conda-forge/noarch)
    +nbformat-5.8.0 (conda-forge/noarch)
    ...
    +notebook-6.5.3 (conda-forge/noarch)
    ...
    +python-3.11.3 (conda-forge/linux-64)

Let me know if there is more info (e.g. from logs) that would be useful for tracking down the issue.

4

I see that your single user servers are JupyterLab instances. So, you mean that the file browser in the JupyterLab is home directory of user instead of /srv/notebooks? If so, try setting up --ContentsManager.root_dir="/srv/notebooks" in your Spawner.args or to a jupyter_server_config file.

5

Thank you, adding c.Spawner.args = ['--ContentsManager.root_dir="/srv/notebooks"'] indeed restored the previous behavior of /srv/notebooks being the root directory shown by JupyterLab.

Could you briefly explain why this additional configuration is necessary when upgrading jupyterhub from 3.1.1 to 4.0.1? I did not find any hint that the configuration of the spawner might have to be changed in the upgrade note in the changelog.

6

Well, I think it has to do with ServerApp config. Which version of jupyter_server are you using before and after upgrade?

I think this PR fixed the problem that you are facing? In our deployment, we have been always using ContentsManager.root_dir and so, we did not face this issue.

7

Interesting. As written above, only jupyterhub and jupyterhub-base changed during the upgrade. jupyter_server remained at version 2.5.0.

8

hmm. The PR that I mentioned was included already in 2.4 so, if you are using already 2.5, it should not affect your deployment. I only thing that I can think about is that in JupyterHub 4, single-user server is implemented as Jupyter server extension which was not the case in JupyterHub 3. This could be a side-effect of that?

9

This should be fixed in JupyterHub 4.0.2 by set root_dir when using singleuser extension by minrk · Pull Request #4503 · jupyterhub/jupyterhub · GitHub