Re: r245005M: NFSv4 usermapping not working anymore

From: Rick Macklem <rmacklem_at_uoguelph.ca>
Date: Fri, 4 Jan 2013 08:30:20 -0500 (EST)
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
Received on Fri Jan 04 2013 - 12:30:22 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:33 UTC