extraVolume (EFS) as ReadOnlyMany not being respected

JupyterHub Zero to JupyterHub on Kubernetes
1

Attempting to add a shared volume preloaded with some data to each singleuser pod that I don’t want users to change.

shared-test.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-test
spec:
  accessModes:
    - ReadOnlyMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 4Gi
  storageClassName: aws-efs-shared

jupyterhub_config.yaml

jupyterhub:
  singleuser:
    storage:
      extraVolumes:
      - name: shared-test
        persistentVolumeClaim:
          claimName: shared-test
      extraVolumeMounts:
      - name:  shared-test
        mountPath: /home/shared/shared-test

The kicker is that when I do a kubectl get pvc I see that it is bound as ReadOnlyMany
shared-test Bound pvc-<redacted> 4Gi ROX aws-efs-shared 22h

if I apply readOnly: true to the extraVolumeMount I lose execute permissions although it does become read only, I think I may need the execute permission to do things like rsync from that dir.

However, it’s mounted in my singleuser container as readwrite and I am able to create new files which persist! I’m using the efs-provisioner helm chart.

2

I think I figured this out, I don’t know how to reproduce what I said above because now, ReadOnlyMany set on the PVC seems to be the culprit of taking away the execute permissions, but doing the readOnly: true bit WITHOUT the ReadOnlyMany bit seems to be working well.

It was sort of challenging to find that piece, I didn’t really see it in any examples but I finally tracked it down in the k8s API, would it be beneficial to link the k8s API to the Configuration Reference — Zero to JupyterHub with Kubernetes documentation section? Anywhere else I could contribute this?

3

Hi!
Could you point us to the relevant bit of the K8s documentation? The best location may depend on whether it’s generic or specific to particular storage/cloud providers.