On Mon, Aug 11, 2008 at 05:29:41PM -0400, Peter Staubach wrote: > J. Bruce Fields wrote: >> 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. >> >> > > What happens if you perform this mount using autofs? I haven't tried yet. --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
