OpenSolaris

During snv_72 testing, it was noticed that the sharemnt testsuite was failing
with sec= mount issues. These issues were not apparent in earlier Nevada builds.

The problem occurs when trying to automount using the sec= option.

Analysis from Helen Chao:

# tail -2 /etc/auto_master
/- /var/tmp/auto_direct.shmnt
/AUTO_shmnt /var/tmp/auto_indirect.shmnt
# cat /var/tmp/auto_indirect.shmnt
# this file is used for indirect auto-map of sharemnt tests
#krb5i -sec=krb5i pnfs-4-06:/export/krb5
krb5i -sec=krb5i vicis:/export/krb5	<== we specified the sec= option
krb5p -sec=krb5p vicis:/export/krb5
v2rokrb5 -vers=2,sec=krb5,rw,vers=2 vicis:/export/krb5
v2krb5i -vers=2,sec=krb5i vicis:/export/krb5
#
# cd /AUTO_shmnt/krb5i			<== now automounting it
# nfsstat -m /AUTO_shmnt/krb5i		<== but we got sec=krb5 (no "i")
/AUTO_shmnt/krb5i from vicis:/export/krb5
 Flags:         vers=4,proto=tcp,sec=krb5,hard,intr,link,symlink,acl,rsize=1048576,wsize=1048576,retrans=5,timeo=600
 Attr cache:    acregmin=3,acregmax=60,acdirmin=30,acdirmax=60

#


Snoop shown that the client tried to negotiate even though
the mount entry specified the "sec=" option.


cura.Central.Sun.COM -> vicis        NFS C NULL4
       vicis -> cura.Central.Sun.COM NFS R NULL4
cura.Central.Sun.COM -> vicis        NFS C NULL4
       vicis -> cura.Central.Sun.COM NFS R NULL4
cura.Central.Sun.COM -> vicis        NFS C 4 (secinfo     ) PUTROOTFH LOOKUP export SECINFO krb5
       vicis -> cura.Central.Sun.COM NFS R 4 (secinfo     ) NFS4ERR_WRONGSEC PUTROOTFH NFS4ERR_WRONGSEC
cura.Central.Sun.COM -> vicis        NFS C 4 (putrootfh   ) PUTROOTFH
       vicis -> cura.Central.Sun.COM NFS R 4 (putrootfh   ) NFS4ERR_WRONGSEC PUTROOTFH NFS4ERR_WRONGSEC
cura.Central.Sun.COM -> vicis        RPC RPCSEC_GSS C 1 (RPCSEC_GSS_INIT)
       vicis -> cura.Central.Sun.COM RPC R (#9) XID=1760638885 Success
cura.Central.Sun.COM -> vicis        NFS C 4 (putrootfh   ) PUTROOTFH
       vicis -> cura.Central.Sun.COM NFS R 4 (putrootfh   ) NFS4_OK PUTROOTFH NFS4_OK
cura.Central.Sun.COM -> vicis        NFS C 4 (secinfo     ) PUTROOTFH LOOKUP export SECINFO krb5
       vicis -> cura.Central.Sun.COM NFS R 4 (secinfo     ) NFS4_OK PUTROOTFH NFS4_OK LOOKUP NFS4_OK SECINFO NFS4_OK RPCSEC_GSS RPCSEC_GSS RPCSEC_GSS
cura.Central.Sun.COM -> vicis        RPC RPCSEC_GSS C 1 (RPCSEC_GSS_INIT)
       vicis -> cura.Central.Sun.COM RPC R (#15) XID=1861302181 Success
cura.Central.Sun.COM -> vicis        NFS C 4 (mount       ) PUTROOTFH GETFH LOOKUP export GETFH GETATTR c8000167 0 LOOKUP krb5 GETFH GETATTR c8000167 0
       vicis -> cura.Central.Sun.COM NFS R 4 (mount       ) NFS4_OK PUTROOTFH NFS4_OK GETFH NFS4_OK FH=47BF LOOKUP NFS4_OK GETFH NFS4_OK FH=821A GETATTR NFS4_OK LOOK...
cura.Central.Sun.COM -> vicis        NFS C 4 (fsinfo      ) PUTFH FH=9C16 GETATTR 20e00000 1c00
       vicis -> cura.Central.Sun.COM NFS R 4 (fsinfo      ) NFS4_OK PUTFH NFS4_OK GETATTR NFS4_OK
cura.Central.Sun.COM -> vicis        NFS C 4 (getattr     ) PUTFH FH=9C16 GETATTR 10011a b0a23a
       vicis -> cura.Central.Sun.COM NFS R 4 (getattr     ) NFS4_OK PUTFH NFS4_OK GETATTR NFS4_OK
cura.Central.Sun.COM -> vicis        NFS C 4 (access      ) PUTFH FH=9C16 ACCESS rd,lk,mo,ext,dl GETATTR 10011a b0a23a
       vicis -> cura.Central.Sun.COM NFS R 4 (access      ) NFS4_OK PUTFH NFS4_OK ACCESS NFS4_OK Supp=rd,lk,mo,ext,dl Allow=rd,lk,mo,ext,dl GETATTR NFS4_OK

A fix has been made available for this, and the webnfs issues (separate CR to be logged), and I will run a number of tests today to verify webnfs and sharemnt are now working. I'll update the CR accordingly when results come back.

The only workaround is to mount using the mount command instead of the automounter.
See comments section for location of fixed binaries based on the onnv_72 snapshot.
Actually there is a server-side workaround.  To ensure that clients
always mount using the desired flavor flavor, make sure the most desired flavor
is first in the flavor list at share time.

N/A