Re: NFSv4 behaviour on unknown users

[Trond Myklebust <Trond.Myklebust@netapp.com>]

On Tue, 2010-11-30 at 12:44 +0100, Spelic wrote:
> On 11/30/2010 01:02 AM, Spencer Shepler wrote:
> >> It would not be backwards compatible: the linux server will currently
> >> reject any uid/gid usage by the client.
> >>
> >> That said, I can imagine that for 'sec=sys', we might be able to change
> >> the client to use the uid/gid format by default, and then change back to
> >> doing name@domain upon receiving the first NFS4ERR_BADOWNER error from the
> >> server.
> >> It the server changes to match this, then that might suffice solve the
> >> current problem that we have with doing nfsroot on NFSv4...
> >>      
> > IMO: I wouldn't worry about the mixed scenarios to start with.
> > Provide the option on the client and server to use the straight-up
> > uid/gid to string mappings and this will satisfy these simple
> > deployments that are or will have trouble.
> >    
> 
> +1 for this.  Changing mapping on the fly at the first NFS4ERR_BADOWNER 
> received does not look very reliable to me: is scarcely controllable by 
> the sysadmin and is gonna make the thing a headache to debug the first 
> time it happens unwillingly (maybe the sysadmin was changing some config 
> on the server and suddenly the everything stops working and he needs to 
> restart the nfs client to restore things but this is scarcely 
> intuitive...). +1 for simply providing a clear-upfront option for using 
> numeric UIDs/GIDs.
> 
> Thanks for your understanding :-)

Sorry, but BADOWNER is an error that means "I don't get it" and the spec
_is_ adamant about what the client should do. This is a take it or leave
it: I'm not going to waste a lot of time and effort on this.

Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com