On Sep 15, 2015, at 1:41 PM, Frank Filz <ffilzlnx@xxxxxxxxxxxxxx> wrote: >> There are two shares on the server. >> >> The share being mounted is /export/CTHON. It is a sys-only share. No > "sec=" >> option is used on the mount command. The expected outcome is that the >> mount will succeed and use sec=sys. >> >> The share that is not being mounted here is /export/KRB5. >> It is shared with at least krb5i, which means the set of flavors the > server >> accepts for the pseudofs includes both krb5i and sys. >> >> The client has already negotiated krb5i to access the pseudofs. I see a >> PUTROOTFH using krb5i and it is successful. The negotiation is not in the > trace >> I have. >> >> I see a number of GETATTRs then a LOOKUP /export, all with krb5i, all >> successful. >> >> Using krb5i, LOOKUP /CTHON, which fails with WRONGSEC. >> >> Client recovers with SECINFO on /CTHON using krb5i. The server responds >> with a list containing just AUTH_UNIX. >> >> Client tries the LOOKUP /CTHON again, now with sys. It works. >> >> Similar GETATTR activity using sys as the client mounts this share. >> >> Then one last GETATTR, this time using krb5i. The FH is the /export/CTHON >> directory. This fails with WRONGSEC. >> >> The attr mask here is Supported Attrs, FH_Expire_type, Link_Support, >> Symlink_Support, ACLSupport. This is from nfs4_server_capabilities(), > which >> is invoked only in nfs4_proc_get_rootfh() and nfs4_proc_get_root(). >> >> The next operation OTW is a RENEW that happens a minute later. > > From that sequence, I'm pretty sure we want to fix this in the client not > the server. > > Hmm, did fsid change? I'm not sure how to tell. The working LOOKUP operations on parent/CTHON always return the same FSID. > Does the mount work if sec=sys is specified? Yes. -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
