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@xxxxxxxxxx www.netapp.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
