jupyterhub / kubespawner

Kubernetes spawner for JupyterHub
https://jupyterhub-kubespawner.readthedocs.io
BSD 3-Clause "New" or "Revised" License
531 stars 299 forks source link

KubeSpawner does not respect uid for mounts #813

Closed Falven closed 6 months ago

Falven commented 6 months ago

I am trying to use static provisioning to mount an Azure Blob Container to a path on my singleuser server. I have set up a PV and PVC and the mounting is working. Additionally I have setup the following securityContext flags:

uid: 1000 # This sets the User ID for the pod to 1000, which corresponds to the jovyan user. It ensures that processes inside the container run as jovyan.
fsGid: 100 # The filesystem group ID to use for the POD (users/100). This determines the group ownership of mounted volumes, ensuring that files and directories within these volumes are accessible by members of the users group.

Unfortunately, it seems that only the fsGid is respected. The mounted volume has the correct group, but is owned by root. These do not work either.

extraPodConfig:
    securityContext:
      runAsUser: 1000
      runAsGroup: 100
      fsGroup: 100

Bug description

I need to be able to properly set the ownership of the mount so that I can read and write to it from uid: 1000. This is imperative as files created in the mount should inherit the ownership, allowing me to read/write to files that were created externally and uploaded to the Azure Blob Storage...

How to reproduce

  1. Configure a Jupyter Stacks image (I am using quay.io/jupyter/base-notebook:latest).
  2. Configure KubeSpawner as outlined above.
  3. Configure a CSI driver (I am using Azure Blob CSI with a PV and PVC)
  4. Start a single user server.
  5. Observe the incorrect mounted volume permissions.

Expected behaviour

The mounted volume should be owned by whatever gid is set. In our case 1000 (jovyan).

Actual behaviour

The mounted volume is owned by root.

Your personal set up

I created a standard installation of zero-to-jupyterhub with default authentication following the AKS guide.

I've tried setting up an initContainer to chown the drive, but it doesn't work reliably. The logs always say the permissions were changed but when I exec in most of the times they are not...

initContainers:
    - name: init-nfs
      image: busybox
      command:
        - 'sh'
        - '-c'
        - |
          echo "Changing permissions for /mnt/data..."
          chown -R 1000:100 /mnt/data && echo "Permissions set successfully." || echo "Failed to set permissions."
      securityContext:
        runAsUser: 0
      volumeMounts:
        - name: azure-blob-volume
          mountPath: /mnt/data
welcome[bot] commented 6 months ago

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively. welcome You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada: