On Mon, Aug 11, 2008 at 04:51:26PM -0400, Peter Staubach wrote: > The Solaris client behaves plus or minus like the Linux client. > It generates a GETATTR unless it receives the attributes via > one of the previous calls. In the Solaris case, it is an FSINFO > call. > > The current Linux NFS server does not return attributes for the > PATHCONF, FSINFO, or FSSTAT calls. Hm. I don't know why that is. > Unless these calls are modified, then the NFSv3 GETATTR will need > to be allowed for the same reason that the NFSv2 GETATTR is > allowed. The NFS client needs, at the very least, the file type > of the node that it is mounting. > > I am confused as to how the testing could have been successful. Well, you can try exporting a filesystem with sec=krb5:krb5i:krb5p (no sys) and try mounting v2 or v3, and you'll see that if fails without the patch, and succeeds with it. But testing again (linux client and server), and taking a network trace this time: I mount with -overs=3,sec=krb5, and the client behavior is odd: FSINFO call with auth_sys GETATTR call with krb5 FSINFO call with krb5 Note that this client actually *does* have access to kerberos credentials--it's just not using them on the initial FSINFO call. That could make some sense if it was trying to ensure the mount will succeed in the absence of kerberos credentials, and doesn't want to bother first trying to get a credentials and then falling back on auth_sys if it doesn't find them. But currently it fails if the server requests auth_sys on the initial FSINFO *or* if it fails to get kerberos credentials for those second two rpc calls. Something similar seems to be true for v2. Huh. Anyway, so in the Solaris v3 case I take it that what you're seeing is FSINFO, GETATTR, both done with auth_sys, and a failure of the mount command if both aren't permitted? OK, so I agree the server should either permit v3 GETATTR (trivial, if arguably contrary to rfc 2623) or add attributes to FSINFO (which I assume is also easy, but I don't know why it was left out before). Seems the client needs some looking at too. --b. -- 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
