problem of chown on a new NFS volume

grocanar — Wed, 04 Jun 2025 13:32:48 GMT

i have a very strange problem with my newly created volume

on our client we mount a netapp namescape

here is the fstab

cns-labgem-n05.genoscope.cns.fr:/cns_labgem_scratch_n05
15360 192 15168 2% /env/export/cns_labgem_scratch_n05

on the netapp we use the cns_labgem_scratch_n05 directory to mount other volume.

for exemple i create a volume vol_bank_test3 and i mount it under cns_labgem_scratch_n05

the volume have root export for the client and the cns_labgem_scratch_n05 have too.

then when i cd in the /env/export/cns_labgem_scratch_n05 directory I got

ls -l
total 24
-rw-r--r-- 1 root root 1820 4 juil. 14:48 result
drwxrws--- 4 coliscope g_agc 4096 30 mai 08:03 scratch_coliscope
drwxrws--- 11 dietetic g_agc 4096 21 juin 14:22 scratch_dietetic
drwxrws--- 5 agc g_agc 4096 16 nov. 2017 scratch_microscope
drwxr-xr-x 2 root root 4096 4 juil. 14:38 vol_bank_test3
drwxr-xr-x 2 agc g_agc 4096 4 juil. 13:26 vol_test

then i want to change the right on thr vol_bank_test3 but it fails

i write a little loop

chown agc:g_agc vol_bank_test3 ; sleep 5 ; for i in `seq 1 20` ; do date ; ls -ld vol_bank_test3 ; sleep 5 ; done | tee /root/result.loop

Result
mer. juil. 4 14:50:45 CEST 2018
drwxr-xr-x 2 agc g_agc 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:50:50 CEST 2018
drwxr-xr-x 2 agc g_agc 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:50:55 CEST 2018
drwxr-xr-x 2 agc g_agc 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:51:00 CEST 2018
drwxr-xr-x 2 agc g_agc 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:51:05 CEST 2018
drwxr-xr-x 2 agc g_agc 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:51:10 CEST 2018
drwxr-xr-x 2 agc g_agc 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:51:15 CEST 2018
drwxr-xr-x 2 agc g_agc 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:51:20 CEST 2018
drwxr-xr-x 2 agc g_agc 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:51:25 CEST 2018
drwxr-xr-x 2 agc g_agc 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:51:30 CEST 2018
drwxr-xr-x 2 agc g_agc 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:51:35 CEST 2018
drwxr-xr-x 2 agc g_agc 4096 4 juil. 14:38 vol_bank_test3

After 60 seconds it came back to root:root

mer. juil. 4 14:51:40 CEST 2018
drwxr-xr-x 2 root root 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:51:45 CEST 2018
drwxr-xr-x 2 root root 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:51:50 CEST 2018
drwxr-xr-x 2 root root 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:51:55 CEST 2018
drwxr-xr-x 2 root root 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:52:00 CEST 2018
drwxr-xr-x 2 root root 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:52:05 CEST 2018
drwxr-xr-x 2 root root 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:52:10 CEST 2018
drwxr-xr-x 2 root root 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:52:15 CEST 2018
drwxr-xr-x 2 root root 4096 4 juil. 14:38 vol_bank_test3
mer. juil. 4 14:52:20 CEST 2018
drwxr-xr-x 2 root root 4096 4 juil. 14:38 vol_bank_test3

on the same time i ran tcpdump on the client

4:50:40.397586 IP etna0.genoscope.cns.fr.1611861186 > cns-labgem-n05.genoscope.cns.fr.nfs: 156 lookup fh 0,128/1073741824 "vol_bank_test3"
14:50:40.398137 IP cns-labgem-n05.genoscope.cns.fr.nfs > etna0.genoscope.cns.fr.1611861186: reply ok 252 lookup fh Unknown/000100001505008000000000400000009643B4B9DE0400800000000040000000
14:50:40.398148 IP etna0.genoscope.cns.fr.946 > cns-labgem-n05.genoscope.cns.fr.nfs: Flags [.], ack 204756191, win 13016, options [nop,nop,TS val 3076348547 ecr 3116358866], length 0
14:51:05.419721 IP etna0.genoscope.cns.fr.1628638402 > cns-labgem-n05.genoscope.cns.fr.nfs: 140 access fh 0,128/1073741824 001f
14:51:05.419893 IP cns-labgem-n05.genoscope.cns.fr.nfs > etna0.genoscope.cns.fr.1628638402: reply ok 120 access c 001f
14:51:05.419907 IP etna0.genoscope.cns.fr.946 > cns-labgem-n05.genoscope.cns.fr.nfs: Flags [.], ack 125, win 13016, options [nop,nop,TS val 3076373569 ecr 3116383889], length 0
14:51:40.447383 IP etna0.genoscope.cns.fr.1645415618 > cns-labgem-n05.genoscope.cns.fr.nfs: 136 getattr fh Unknown/000100001505008000000000400000009643B4B9DE0400800000000040000000
14:51:40.460694 IP cns-labgem-n05.genoscope.cns.fr.nfs > etna0.genoscope.cns.fr.1645415618: reply ok 112 getattr DIR 755 ids 0/0 sz 4096
14:51:40.460711 IP etna0.genoscope.cns.fr.946 > cns-labgem-n05.genoscope.cns.fr.nfs: Flags [.], ack 241, win 13016, options [nop,nop,TS val 3076408610 ecr 3116418930], length 0

then i can see that the client never ask to the netapp the attributes of the directory before 60 seconds

moreover in the same time on another client that mount the same diretory i always got

drwxr-xr-x 2 root root 4096 4 juil. 14:38 vol_bank_test3

Then i concluded that the netapp silently discard the chown command.

Is there a way to see why it silently discard the command?

Re: problem of chown on a new NFS volume

storageguy — Wed, 11 Jul 2018 00:01:11 GMT

What rules have set on the export? If you let the (NFS client)system (superuser=sys) to assign the permission, then whatever permission on the mount path (from the client) will be inherited.

Hope that helps.

Re: problem of chown on a new NFS volume

grocanar — Fri, 28 Sep 2018 08:22:55 GMT

Thans for your answer

in fact it was a problem with the cmliednt which doesn't support the junction path of the netapp

after upgrade it works like a charm

topic Re: problem of chown on a new NFS volume in ONTAP Discussions

problem of chown on a new NFS volume

Re: problem of chown on a new NFS volume

Re: problem of chown on a new NFS volume