Chuck Lever wrote: > On Aug 21, 2009, at 3:07 PM, Thomas Haynes wrote: >> Sent from my iPhone >> >> On Aug 21, 2009, at 1:24 PM, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> >> wrote: >> >>> On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote: >>>> I want to understand the server bug a little more. I glanced over RFC >>>> 2623 and didn't see anything specific. >>>> >>>> Is it the case that only Linux NFSD does this, or do other servers do >>>> it? In other words, is this a typical server response, and if so, is >>>> there a specific semantic attached to it? >>>> >>>> If no list is provided, should the client assume that only AUTH_NONE >>>> and >>>> AUTH_SYS are supported, or instead, perhaps that the client can try to >>>> use any flavor? In other words, if no list is provided, let the mount >>>> proceed no matter what was specified by sec= ? >>> >>> I think the safest behavior on the client would be something like: >>> >>> - If an explicit sec= is provided on the client, try that >>> flavor. Otherwise: >>> - If the server returned a nonempty list, pick something >>> off that list. Otherwise: >>> - Try auth_sys. >>> >> >> Which is pretty much what we do. The exception being that the default >> flavor is a setting - and probably always AUTH_SYS... > > I'm still not sure what is the right thing to do here. Looking at 1813, > it says: > > DESCRIPTION > Procedure MNT maps a pathname on the server to a file > handle. The pathname is an ASCII string that describes a > directory on the server. If the call is successful > (MNT3_OK), the server returns an NFS version 3 protocol > -> file handle and a vector of RPC authentication flavors > -> that are supported with the client’s use of the file > -> handle (or any file handles derived from it). The > authentication flavors are defined in Section 7.2 and > section 9 of [RFC1057]. > > IMPLEMENTATION > If mountres3.fhs_status is MNT3_OK, then > mountres3.mountinfo contains the file handle for the > -> directory and a list of acceptable authentication > -> flavors. This file handle may only be used in the NFS > version 3 protocol. This procedure also results in the > server adding a new entry to its mount list recording that > this client has mounted the directory. AUTH_UNIX > authentication or better is required. > > This suggests pretty clearly that the client should treat the returned > auth flavor list as the list of flavors supported for this mount point, > not as a preference list to be used only if the client is trying to > guess what flavor to use. Is my reading incorrect? Help! :-) > Your interpretation is the correct one, Chuck. The list returned from the server is supposed to be the definitive list of authentication flavors that the server will accept from the client. A server which returns no flavors is by definition, broken. ps > >> >> >> >>> --b. >>> >>>> >>>> Thanks for any clarification. >>>> >>>> Begin forwarded message: >>>> >>>>> From: Trond Myklebust <trond.myklebust@xxxxxxxxxx> >>>>> Date: August 20, 2009 10:36:11 PM GMT-04:00 >>>>> To: Wu Fengguang <fengguang.wu@xxxxxxxxx>, "Mr. Charles Edward Lever" >>>>> <Chuck.Lever@xxxxxxxxxx> >>>>> Cc: "linux-nfs@xxxxxxxxxxxxxxx" <linux-nfs@xxxxxxxxxxxxxxx>, LKML >>>>> <linux-kernel@xxxxxxxxxxxxxxx> >>>>> Subject: Re: mount.nfs: access denied by server >>>>> >>>>> On Fri, 2009-08-21 at 09:27 +0800, Wu Fengguang wrote: >>>>>> On Thu, Aug 20, 2009 at 09:02:29PM +0800, Trond Myklebust wrote: >>>>>>> On Thu, 2009-08-20 at 15:13 +0800, Wu Fengguang wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> After upgrading NFS client kernel to latest linux-next, NFS mount >>>>>>>> failed: >>>>>>>> >>>>>>>> # mount -t nfs pxe:/cc /cc >>>>>>>> mount.nfs: access denied by server while mounting pxe:/cc >>>>>>>> >>>>>>>> # uname -a >>>>>>>> Linux hp 2.6.31-rc6-next-20090818 #61 SMP Thu Aug 20 >>>>>>>> 14:46:10 CST 2009 x86_64 GNU/Linux >>>>>>>> >>>>>>>> However server log says OK: >>>>>>>> >>>>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated mount >>>>>>>> request from 192.168.11.6:973 for /cc (/cc) >>>>>>>> Aug 20 15:02:09 wu-t61 mountd[4599]: authenticated unmount >>>>>>>> request from 192.168.11.6:974 for /cc (/cc) >>>>>>>> >>>>>>>> However-2: nfsroot can be mounted at boot time. Server kernel has >>>>>>>> always been 2.6.30. >>>>>>>> >>>>>>>> Any ideas? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Fengguang >>>>>>> >>>>>>> Can you try again after enabling mount debugging on the NFS client? >>>>>>> >>>>>>> echo 512 > /proc/sys/sunrpc/nfs_debug >>>>>> >>>>>> I used 1024 and found the mount failed here in nfs_walk_authlist(): >>>>>> >>>>>> dfprintk(MOUNT, "NFS: server does not support requested auth >>>>>> flavor\ n"); >>>>>> nfs_umount(request); >>>>> >>>>> Thanks Fengguang! >>>>> >>>>> Chuck, this looks like one of yours. Could it be that you are hitting >>>>> the same Linux knfsd bug that Tom Haynes saw with a Solaris client? >>>>> AFAICR, the problem was that existing nfs servers do not set a default >>>>> auth flavour, and so you just have to try with auth_sys and see if it >>>>> succeeds... >>>>> >>>>> Cheers >>>>> Trond >>>>> >>>> >>>> -- >>>> Chuck Lever >>>> chuck[dot]lever[at]oracle[dot]com >>>> >>>> >>>> > > -- > Chuck Lever > chuck[dot]lever[at]oracle[dot]com > > > > -- > 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 -- 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
