> 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. I should have been more clear... Is the fsid for /export different from the fsid for /export/CTHON? If it changes that should produce a new superblock. > > Does the mount work if sec=sys is specified? > > Yes. And with different mount options, a different superblock should definitely be created. I wonder if there is some way we can push up the security negotiation to help identify a new superblock is necessary, equivalent to having a different mount option? Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- 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
