Capability to set filesystem permissions for mounted volumes

[seifrajhi]

What happened:

I am not able to change the permissions of the files mounted using azure-file-csi-persistent in azure provider.
My directory are getting mounted as root with 770 permissions, while I want my mounted files to have 750 permissions and nonroot user.

I want to avoid ownership changes of the mount volume /app from azure-file-csi-persistent storage class inside my pod?

I created the following in my Dockerfile:

RUN groupadd nonroot -g 2000 && \
    useradd -r -M -s /sbin/nologin -g nonroot -c nonroot nonroot -u 1000 && \
RUN mkdir /app \
    && chown nonroot:nonroot /home /app \
    && chmod 750 /app
USER nonroot

However, it is mounted with 50000:root ownership when I check inside the pod, which I think is inherited from CSI. Here is the CSI configuration:

mountOptions:
  - dir_mode=0770
  - file_mode=0770
  - uid=50000
  - gid=0
  - actimeo=30
  - nosharesock

What you expected to happen:

I expected the /app directory to retain the 1000:2000 ownership set in the Dockerfile, rather than being overridden by the CSI mount options.

How to reproduce it:

1. Create a Dockerfile with the specified user and group settings.
2. Deploy a pod with a volume mounted using the specified CSI configuration.
3. Check the ownership of the mounted directory inside the pod.

Anything else we need to know?:

Any guidance on using fsGroup and/or fsGroupChangePolicy to maintain the desired ownership would be greatly appreciated.

Environment:

• CSI Driver version: v1.29.8
• Kubernetes version (use kubectl version): Client Version: v1.30.3, Server Version: v1.28.13
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

[andyzhangx]

@seifrajhi why not set the required permission in mount options, the volume permission can only be determined in the first mount with mount options.

  - dir_mode=0750
  - file_mode=0750
  - uid=nonroot
  - gid=nonroot

[seifrajhi]

@seifrajhi why not set the required permission in mount options, the volume permission can only be determined in the first mount with mount options.

  - dir_mode=0750
  - file_mode=0750
  - uid=nonroot
  - gid=nonroot

We are using this shared volume in different pods(i.e deployments), and a part of these pods need root privilege and we have exception for those pods.

However, when possible we want to use nonroot user to mount the volume.

One more thing is that the nonroot name differs from deployment to another, for instance we have atlantis, gitsync airflow, etc.

[andyzhangx]

@seifrajhi those mount options are per volume setting, if you have two pods that need different permissions, you could define two PVCs pointing to the same file share with different mountOptions.

[seifrajhi]

Thank you @andyzhangx, I thought that mountOptions cannot be specified directly in a PVC manifest.

My context is that I have an Airflow application that mounts a volume called dags created by a PVC called dags-pvc using the Azure file storageClass, which contains all the DAGs.
Additionally, I have a GitSync application that needs to mount the same volume to synchronize the DAGs between Azure DevOps and the Airflow dags volume. Therefore, both applications should mount the same PVC to ensure they access the same content.

If I can create two PVCs that point to the same content in the file share with different mountOptions specified at the StorageClass or PV level, and mount each to its corresponding pod that would solve my issue.

[andyzhangx]

@seifrajhi you could create two PVs, each PV would have different mountOptions, and bound to different PVC, that should work. Make sure the volumeHandle value of your two PVs are different.

[seifrajhi]

@andyzhangx, sure, I will do that thanks a lot. But this would defy the dynamic provisioning feature of StorageClasses, right ? which we leverage to create PVs on the fly.

[andyzhangx]

then you could define two storage classes with different mountOptions