Date: Fri, 4 Jan 2013 08:30:20 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: "O. Hartmann" <ohartman@zedat.fu-berlin.de> Cc: Current FreeBSD <freebsd-current@FreeBSD.org> Subject: Re: r245005M: NFSv4 usermapping not working anymore Message-ID: <416983367.1668162.1357306220561.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <50E6AB65.5030309@zedat.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?416983367.1668162.1357306220561.JavaMail.root>