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