Re: NFSv4 behaviour on unknown users

[Boaz Harrosh <bharrosh@panasas.com>]

On 11/30/2010 03:04 PM, Trond Myklebust wrote:
> 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.
> 

Perhaps a BIG FAT message in dmsg should help the poor admin investigating
the matter.

Thanks
> Trond
>