Subscribe

problem of chown on a new NFS volume

Hi

 

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

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.