Mount options not being used?

[luke-barnett]

I need to set uid and gid for proper permissions within a container and I can't seem to get the it working as expected.

Here is my pv

--- apiVersion: v1 kind: PersistentVolume metadata: annotations: pv.kubernetes.io/provisioned-by: smb.csi.k8s.io name: pv-storage-smb spec: capacity: storage: 100Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain storageClassName: smb mountOptions: - dir_mode=0755 - file_mode=0644 - uid=1000 - gid=1000 - forceuid - forcegid csi: driver: smb.csi.k8s.io readOnly: false volumeHandle: data.host/storage##pv volumeAttributes: source: "//data.host/storage" nodeStageSecretRef: name: smb-creds namespace: csi-driver-smb

When checking the mounts on the node and from the container it's all still set as uid=0?

Checking the mount definitions on the host I have by running mount | grep cifs I get the following:

//data.host/storage on /var/lib/kubelet/pods/37205acf-fb2b-4a0c-8a5b-f0857e8407da/volumes/kubernetes.io~csi/pv-storage-smb/mount type cifs (rw,relatime,vers=3.1.1,cache=strict,username=srv-k3s,uid=0,noforceuid,gid=0,noforcegid,addr=,file_mode=0777,dir_mode=0777,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)

which to me suggests that it's completely ignoring the mount options? I manually mounted the same share with uid/gid settings to confirm that the host/server supports those mount options and that worked fine. Not sure what I'm missing?

[luke-barnett]

I’ve noted that I have different behavior between nodes, Ubuntu nodes are completely fine, but Debian nodes are forcing to root.

[luke-barnett]

The answer seems to be that I needed to force down the mount as it was reusing it and justing binding in for the actual volume?

I did this by restarting the node completely, but is there a more sane way to achieve this?

[andyzhangx]

the application pods that reference the Azure file volume should be restarted after the mount options has been updated. In cases where two pods share the same PVC on the same node, it is necessary to reschedule the pods to a different node without that PVC mounted to ensure that remounting occurs successfully.