Trident NFS volumes set all users as nobody | NetApp | Page 1

patent umbra Jul 17, 2025, 12:36 AM

#

Hi All,

We have the following backend for the NFS :

  autoExportCIDRs:
  - 10.0.1.0/24
  autoExportPolicy: true
  backendName: netapp-trident-ontap-nfs
  credentials:
    name: netapp-svm-creds-lt
  dataLIF: 10.0.1.1
  limitVolumeSize: 4999Gi
  managementLIF: 10.0.2.1
  storageDriverName: ontap-nas
  storagePrefix: trident_
  svm: xxxxx
  version: 1

Everything works fine, the files in all the volumes are owned by user nobody:

(/home/jovyan/python-3.13) jovyan@jupyter:~$ ls -al
total 28
drwxrwxrwx. 8 nobody nogroup 4096 Jul 15 04:43 .
drwxrwxrwx. 3 root   root      20 Jul 14 01:25 ..
drwxr-xr-x. 3 nobody nogroup 4096 Jul 15 00:30 .cache
drwxrwsr-x. 2 nobody nogroup 4096 Jul 15 00:30 .conda
drwxr-xr-x. 2 nobody nogroup 4096 Jul 14 01:25 .ipython
drwxr-xr-x. 3 nobody nogroup 4096 Jul 14 01:25 .jupyter
drwxr-xr-x. 3 nobody nogroup 4096 Jul 14 01:25 .local
drwxr-xr-x. 3 nobody nogroup 4096 Jul 14 01:25 .npm
-rw-r--r--. 1 nobody nogroup    0 Jul 15 04:43 test12
(/home/jovyan/python-3.13) jovyan@jupyter:~$

Regular users can read and write, but we're unable to change the ownerships, even with root. Can someone point me to what I may've done wrong?

Cheers,
Ko

midnight cape Jul 17, 2025, 12:51 AM

#

The users and groups used inside a container has nothing to do with the Trident backend. It has to do with how you setup the pod. See https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ for what you need to set.

Kubernetes

Configure a Security Context for a Pod or Container

A security context defines privilege and access control settings for a Pod or Container. Security context settings include, but are not limited to:
Discretionary Access Control: Permission to access an object, like a file, is based on user ID (UID) and group ID (GID).
Security Enhanced Linux (SELinux): Objects are assigned security labels.
Runni...

patent umbra Jul 17, 2025, 12:54 AM

#

Hi @midnight cape , I have a PodSecurityContext and the ContainerSecurityContext, they work fine, but the when the applications are writing to the volume, they're always owned by nobody or the uid 65534.

#

Example is from JupyterHub running on the kubernetes cluster with PV backend via Trident

#

for example:

(/home/jovyan/python-3.13) jovyan@jupyter:~$ id 
uid=1000(jovyan) gid=100(users) groups=100(users)
(/home/jovyan/python-3.13) jovyan@jupyter:~$ touch my_new_file.txt
(/home/jovyan/python-3.13) jovyan@jupyter:~$ ls -la my_new_file.txt 
-rw-r--r--. 1 nobody nogroup 0 Jul 17 00:55 my_new_file.txt
(/home/jovyan/python-3.13) jovyan@jupyter:~$ chown 1000:100 my_new_file.txt 
chown: changing ownership of 'my_new_file.txt': Operation not permitted
(/home/jovyan/python-3.13) jovyan@jupyter:~$

#

(/home/jovyan/python-3.13) jovyan@jupyter:~$ df -h .
Filesystem                                                     Size  Used Avail Use% Mounted on
10.0.1.1:/trident_pvc_10593d70_5de7_4728_ad6d_a977da8a7bb4  100G  4.7M  100G   1% /home/jovyan
(/home/jovyan/python-3.13) jovyan@jupyter:~$

muted thicket Jul 17, 2025, 9:33 AM

#

Try mounting with NFS3 (Mount option nfsvers=3)

patent umbra Jul 17, 2025, 11:10 AM

#

Already tried, it's the same

midnight cape Jul 17, 2025, 12:34 PM

#

From the node, what are the mount options for a mount showing this behavior? (Output of 'mount | grep pvc' command)

patent umbra Jul 18, 2025, 3:35 AM

#

(rw,relatime,vers=4.2,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=null,clientaddr=10.0.1.11,local_lock=none,addr=10.0.1.1)

#

Ok just noticed: sec=null

#

this should be sec=sys? if not netapp would push all ownership to the default user 65534?

#

I can set the mountOptions in the backend config?

patent umbra Jul 18, 2025, 4:13 AM

#

Yep, that fixed it... I had to add:

nfsMountOptions:vers=4.2,hard,nointr,rsize=8192000,wsize=8192000,timeo=10,retrans=2,sec=sys

muted thicket Jul 18, 2025, 7:00 AM

#

patent umbra this should be sec=sys? if not netapp would push all ownership to the default us...

it depends on your rwrule, rorule and superuser settings on what happens with sec=null... but yeah I would suggest to mount with sec=sys, I mean it's not much security but it's better than none 😉

#

also I would consider changing the rsize/wsize to a smaller value. From my experience (and NetApp seems to agree), rsize/wsize of 256k to 1MB perform best. But that of course depends on your application and if you have tested 8M to be the fastest, then leave it as-is of course

midnight cape Jul 18, 2025, 12:18 PM

#

Was this using RHCOS?

patent umbra Jul 20, 2025, 10:28 PM

#

muted thicket it depends on your rwrule, rorule and superuser settings on what happens with se...

rwrule and rorule was set to any should it be setting to sys?

patent umbra Jul 20, 2025, 10:29 PM

#

midnight cape Was this using RHCOS?

No this is pure play kubernetes with kubeadm / kubespray

muted thicket Jul 20, 2025, 10:34 PM

#

patent umbra rwrule and rorule was set to `any` should it be setting to `sys`?

sys means it will require sec=sys security. any and none means it can work with sec=null. I would always use sys if possible

patent umbra Jul 20, 2025, 10:43 PM

#

muted thicket also I would consider changing the rsize/wsize to a smaller value. From my exper...

I thought setting it to the 8k would be ideal since a blocks would line up with jumbp frames it self. But the defaul was 64k

muted thicket Jul 20, 2025, 10:43 PM

#

you set it to 8M not 8k

patent umbra Jul 20, 2025, 10:44 PM

#

Let me play with 8M like you suggested... see how well that fairs 🙂

#

Thanx for all the help

mighty wadi Jul 24, 2025, 7:30 PM

#

[-tcp-max-xfer-size <integer>] - TCP Maximum Transfer Size (bytes) (privilege: advanced)
This optional parameter specifies the maximum transfer size (in bytes) that the storage system negotiates with the client for TCP transport of data for NFSv3 and NFSv4.x protocols. The range is 8192 to 1048576. The default setting is 65536 when created. Warning: Increasing/decreasing the value of this parameter could affect the performance for existing connections.

#Trident NFS volumes set all users as nobody