wondering how the negotiation of the sec level work in nfsv4

grocanar · ‎2023-10-13

Hi

i have a problem with a centos7 server and a netapp cluster

my cluster is using dataontap 9.13P1

when i try to mount a volume for a svm i got the sec=null

cng-svm-seq-647-h05.cng.fr:/v_joliotcurix on /env/export/v_joliotcurix type nfs4 (rw,nosuid,nodev,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=null,clientaddr=195.83.222.84,local_lock=none,addr=172.24.138.81)

but another volume i got sec=sys
cng-svm-ng-647-h06.cnrgh.fr:/q_images on /env/export/container_images type nfs4 (rw,nosuid,nodev,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=195.83.222.84,local_lock=none,addr=172.24.138.63)

The configuraiton of the nfs server on the two svm are purely identical.

and when i force the first mount with the option sec=sys i got no error and it work as expected.

is there some way i can debug this problem?

grocanar · ‎2023-10-13

i have mad another test

i create a test volume

i put this export policy

vserver export-policy rule create -vserver cns_svm_seq -clientmatch 195.83.222.84 -rorule sys -policyname test -rwrule sys

when i mount the share without option i got
cns-svm-seq-647-n12.seq.local:/test on /mnt type nfs4 (rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=
195.83.222.84,local_lock=none,addr=172.24.138.73)

Then the negociation succeeded
if i change the export policy
vserver export-policy rule modify -vserver cns_svm_seq -clientmatch 195.83.222.84 -rorule any -policyname test -rwrule any -ruleindex 1

then when i launch the same command aka a mount without specifying the sec value i got
cns-svm-seq-647-n12.seq.local:/test on /mnt type nfs4 (rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=null,clientaddr
=195.83.222.84,local_lock=none,addr=172.24.138.73)

the negotiation failed

TMACMD · ‎2023-10-14

It may be the client is trying to use a security mechanism that is not supported by ONTAP.

I’m not a fan of using “any” for the auth mechanisms I prefer to use sys unless I know the client will be doing something else

grocanar

Hi
I got the problem again and i further investigate.
i tcpdump the request and got the response for negotiation
Here is the answer from the netapp for a SECINFO

Opcode: SECINFO_NO_NAME (52)
            Status: NFS4_OK (0)
            Flavors Info
                num: 5
                flavor: AUTH_NULL (0)                     <===== 
                flavor: RPCSEC_GSS (6)
                    oid: <DATA>
                        length: 9
                        contents: <DATA>
                        fill bytes: opaque data
                    qop: 0
                    service: rpcsec_gss_svc_privacy (3)
                flavor: RPCSEC_GSS (6)
                    oid: <DATA>
                        length: 9
                        contents: <DATA>
                        fill bytes: opaque data
                    qop: 0
                    service: rpcsec_gss_svc_integrity (2)
                flavor: RPCSEC_GSS (6)
                    oid: <DATA>
                        length: 9
                        contents: <DATA>
                        fill bytes: opaque data
                    qop: 0
                    service: rpcsec_gss_svc_none (1)
                flavor: AUTH_UNIX (1)

I guess the problem is with with AUTH_NULL at the first place