FIle Permission squashing to NOBODY

[anvpetrov]

Files created on NFS PV downgrade permissions to NOBODY

Environment

• Trident version: 21.01.1
• Trident installation flags used: [trident -n trident install]
• Container runtime: crio 1.19
• Kubernetes version: 1.19
• Kubernetes orchestrator: Openshift 4.6.20
• Kubernetes enabled feature gates:
• OS: CoreOS 4.6
• NetApp backend types: ONTAP
• Other:

Steps to reproduce the behavior:

1. create pvc
2. map it to deployment
3. open container console
4. create file on PV mount point
5. File owner 99(nobody)

Expected behavior Owner of file user with openshift range UID

On node I see that share mounted with sec=null On enother cluster, when all working fine sec=sys

[balaramesh]

@anvpetrov you can enforce file ownership in Kubernetes using fsGroups as follows:

1. Make sure the StorageClass used to create PVCs has parameter.fsType defined. Example manifest is here
2. Provide securityContext.fsGroup for RWO PVCs, and supplementalGroups for RWX PVCs. Example manifest is here

[balaramesh]

In addition, you should also take a look at https://github.com/NetApp/trident/issues/269.

Moreover, the share is likely being mounted as sec=null because of the idmapper config on your RHCOS nodes (/etc/idmapd.conf). You will need to set the realm to be the same as configured on ONTAP.

[anvpetrov]

Thank you for response.

I will add that my user in container is not root. His uid is for example 101234100

I have several clusters with same storage class and backend.json , but only on this cluster I have a problem with squashing

[anvpetrov]

In addition, you should also take a look at #269.

Moreover, the share is likely being mounted as sec=null because of the idmapper config on your RHCOS nodes (/etc/idmapd.conf). You will need to set the realm to be the same as configured on ONTAP.

idmaper is disabled by default $ cat /sys/module/nfs/parameters/nfs4_disable_idmapping Y

On netapp option superuser = any

[megabreit]

@anvpetrov Why do you disable the idmapper? It's probably the reason for your problems. It's simple to configure. Just think about a realm, just a simple text string, and configure it on RHCOS and on the SVM.

[paraenggu]

@balaramesh although it's a rather oldish issue/comment, I would be interested in some background on your following statement (the second part regarding the RWX PVCs):

you can enforce file ownership in Kubernetes using fsGroups as follows:

1. Make sure the StorageClass used to create PVCs has parameter.fsType defined. Example manifest is here

2. Provide securityContext.fsGroup for RWO PVCs, and supplementalGroups for RWX PVCs. Example manifest is here

For ontap-nas backed RWX PVCs: How will the group specified in the supplementalGroups be reflected on the NFS root directory? i.e what ensures that the directory group ownership matches with the group specified in supplementalGroups?

Thanks a lot!

[sjpeeris]

@paraenggu Please let us know if this issue still exists with the newer versions of Trident.

[sjpeeris]

Closing. Please re-open if you notice this issue with newer versions of Trident.