Real utility of idmapd

[Guillaume Rousse]

Kevin Coffman wrote:
> On 3/22/07, Guillaume Rousse <Guillaume.Rousse at inria.fr> wrote:
>> J. Bruce Fields wrote:
>> >> >From the logs, the server seems to map ids on name, not names on id:
>> >> Mar 20 15:33:52 stalingrad rpc.idmapd[19602]:  Server: (user) id "501"
>> >> -> name "nobody"
>> >> Mar 20 15:33:52 stalingrad rpc.idmapd[19602]: nfsdcb:
>> >> authbuf=oberkampf.msr-inria.inria.fr authtype=group
>> >> Mar 20 15:33:52 stalingrad rpc.idmapd[19602]:  Server: (group) id
>> "501"
>> >> -> name "nogroup"
>> >>
>> >> So name-based mapping appears to be working upside down here...
>> >
>> > The above is expected.  For example, if the client is stat'ing a file,
>> > then the server must translate the uid and gid stored in the file's
>> > inode into a string name that an NFSv4 client will understand.
>> It works on the client, indeed: files owned by uid 501 on the server
>> appears to be owned by user of the same name on the client, even if he
>> has a different uid there (500).
>>
>> My point it that on the server (stalingrad), file created from the
>> client use wrong uid (501), instead of being correctly mapped to uid 500.
> 
> You claim the file is created with the "wrong uid" on the server.
> Yet, an "ls -l" on that file on the server and on the client will
> result in the same name, right? 
No. ls -l on the server attributes it to nobody, because uid 501 doesn't
exist there. It should have been 500 if the mapping succedeed.