r245005M: NFSv4 usermapping not working anymore

O. Hartmann ohartman at zedat.fu-berlin.de
Fri Jan 4 14:56:50 UTC 2013


Am 01/04/13 14:30, schrieb Rick Macklem:
> O. Hartmann wrote:
>> Since yesterday's update and buildworld on two FreeBSD 10.0-CURRENT
>> boxes, i realize a strange behaviour. I have one server exporting via
>> NFSv4 several ZFS volumes. The UID mapping went pretty well so far,
>> but
>> with a reboot of yesterday (after a buildworld), files are seen with
>> uid
>> root:wheel and users are no longer seen.
>>
> You might want to check (ifconfig -a) and see that there is a mapping
> for 127.0.0.1 for lo. That is what is used to do the upcall to nfsused
> and some systems have had this missing recently. (I had the impression
> that the problem was caused by r244678, which was reverted by r244989,
> but maybe your system still has that issue.)
> 
> Here's basically how it works, which may help with diagnosing what is
> going on:
> - when the nfsuserd starts up, it pushes a DNS domain (usually the
>   hostname with the first component stripped off) plus a couple of
>   hundred mappings acquired via getpwent()/getgrent() into the kernel
>   cache.
> (The easiest way to break it for all users is to have the wrong DNS
>  domain name. "man nfsuserd" gives you a command line option that can
>  override the default of using the hostname.)
> - Then the nfsuserd waits for upcalls for cache misses and pushes
>   mappings for those requests into the kernel.
> - The cache entries time out with a rather long default of 1hr.
> 
> To get entries, nfsused just uses the getpwent() and getgrent() libc
> calls, so it depends on whatever you have configured for that via
> /etc/nsswitch.conf.
> 
> I'll grab a new kernel and do a quick test, to see if it works ok for me.
> (The most recent commit related to this is r240720, which added support
>  to the client for numeric uids/gids in the string on the wire. This change
>  should not have affected the server.)
> 
> Good luck with it, rick
> 
>> The server and client in question are
>>
>> server: FreeBSD 10.0-CURRENT #2 r245005M: Thu Jan 3 20:25:00 CET 2013
>> client: FreeBSD 10.0-CURRENT #2 r245005M: Thu Jan 3 20:27:25 CET 2013
>>
>> I think this is not supposed to be that way. Another box, our lab's
>> server, doesn't show this phenomenon (but at the moment I have only
>> the
>> opportunity to check with a FreeBSD 9.1-STABLE client). This specific
>> server is
>>
>> server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan 2 12:06:13 CET 2013
>>
>> By the way, can someone give me a hint why some boxes show up with an
>> attached "M" to the SVN revision number (like r245005M)?
>>
>> Thanks,
>>
>> oh


Me stupid killed the nfsuserd="YES" entry in rc.conf on the client side!
So, by starting it again, everything works as before and expected.

Many thanks for the quick response!

Oliver

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20130104/0a0c53c9/attachment.sig>


More information about the freebsd-current mailing list