fsGroup does not work with local-path volume

benzman81 commented 2 years ago

Actual Behavior

With current Local Path Provisioner v0.0.21 the storage class local-path mounts with hostPath. This prevents the use of fsGroup and causes permission problems.

Steps to Reproduce

Create a simple non-root pod with a persistent volume claim using local-path storage. Then try to write a file into this mounted directory as non root user. This will not work as permissions of the mounted directory is still root:root.

Result

Mounted directory is still root:root and you cannot write into it.

Expected Behavior

Use Local Path Provisioner v0.0.23. With this version you can annotate a volume claim to use local instead of hostPath. Using local works with fsGroup.

Additional Information

No response

Rancher Desktop Version

1.6.1

Rancher Desktop K8s Version

v1.24.6

Which container engine are you using?

moby (docker cli)

What operating system are you using?

Windows

Operating System / Build Version

Windows 10 20H2

What CPU architecture are you using?

x64

Linux only: what package format did you use to install Rancher Desktop?

No response

Windows User Only

Not relevant.

benzman81 commented 2 years ago

I case some needs to work around it you can patch it.

Create a file patch.yaml:

spec:
  template:
    spec:
      containers:
        - name: local-path-provisioner
          image: rancher/local-path-provisioner:v0.0.23

Then run kubectl -n kube-system patch deployment local-path-provisioner --patch-file patch.yaml.

adamkpickering commented 2 years ago

I'm going to write down a summary of the above, because it took me a long time to understand what you are trying to do. If you wouldn't mind confirming that everything below is correct, that would help.

It sounds like you want to be able to create a Pod that has a non-root user in it. You want to mount a PersistentVolume into it that has been created by the local-path StorageClass via a PersistentVolumeClaim. However, the non-root user in the Pod cannot use the mounted volume, because it is mounted into a directory that is owned by user root and group root. Using the fsGroup in the securityContext part of the Pod manifest doesn't solve the problem, because the hostPath volume type, which the local-path StorageClass uses by default, appears to not respect it. The workaround is to use the local volume type, which local-path can be told to use via an annotation, but only in local-path v0.0.23.

If all of that is accurate, then this isn't the right place to submit an issue. Once you select the version of k8s that you want, Rancher Desktop downloads k3s into the VM and runs that. The latest version of k3s (1.25.3+k3s1) packages local-path v0.0.21. If you want Rancher Desktop to have local-path v0.0.23, you need to request that from the k3s folks, and they need to create a release with it, at which point you'll be able to get it through Rancher Desktop. We can keep this issue open in the meantime. Let me know if I misunderstood anything 😄

benzman81 commented 2 years ago

@adamkpickering got you. I submitted the bug at https://github.com/k3s-io/k3s/issues/6401

rancher-sandbox / rancher-desktop