Closed kkapper closed 2 months ago
This is outside the control of Z2JH or JupyterHub. JupyterHub starts the singleuser container, but everything that happens inside that container is controlled by jupyter-server, JupyterLab, or whatever you've installed in your container.
If you think you've found a bug in jupyter-server or JupyterLab can you open an issue on the relevant repository? Thanks!
Hi there @kkapper :wave:!
I closed this issue because it was labelled as a support question.
Please help us organize discussion by posting this on the https://discourse.jupyter.org/ forum. If it's your first time posting please read https://discourse.jupyter.org/t/getting-good-answers-to-your-questions/1825. The more information you provide the more likely we can help you.
Our goal is to sustain a positive experience for both users and developers. We use GitHub issues for specific discussions related to changing a repository's content, and let the forum be where we can more generally help and inspire each other.
Thanks you for being an active member of our community! :heart:
Bug description
Suppose you are mounting additional volumes to singleuser pods and not generating a PV on a per-user basis.
(This is a common use case if you are using some kind of elastic file system or buckets to back your volume claims.)
A user can then in the UI attempt a rename on one of these directories.
The rename behavior seems to attempt to run a
mv
command, which will effectively empty the directory and move its contents to whatever the new folder name specified was.Even if the UI claims the rename has failed, the source directory is still empty, and the contents have been moved to the new directory.
Because only the path specified is being maintained by the external storage provisioner, all data would be lost from the source directory.
How to reproduce
Boot a singleuser pod and add some files to this directory.
Rename the directory in the UI.
Expected behaviour
If the rename fails for any reason, the move process should probably just stop dead in its tracks.
What might be even better is allowing us to set permissions on directories from the jupyterhub side and just notify users that renaming these persistence backed directories is not allowed.
Actual behaviour
The rename errors, but all the files have been moved to another directory which is not backed by persistence.
Your personal set up
We use the standard helm chart here: https://github.com/jupyterhub/zero-to-jupyterhub-k8s
current chart version: 3.0.3
paste relevant logs here, if any