Re: r245005M: NFSv4 usermapping not working anymore
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE1FA6F100C8E3CE763C93D9B
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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.)
>=20
> 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.
>=20
> 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.
>=20
> I'll grab a new kernel and do a quick test, to see if it works ok for m=
e.
> (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 ch=
ange
> should not have affected the server.)
>=20
> Good luck with it, rick
>=20
>> 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=3D"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
--------------enigE1FA6F100C8E3CE763C93D9B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
iQEcBAEBAgAGBQJQ5u2vAAoJEOgBcD7A/5N8yngIAMigBSnTb5uH/GdalzwhOs0Q
iglQB7wWuF47YFhSX64QjC2nwUnUV8SwybUS5Z30S2ob4RJNCkPGv7Effc4qi5a3
bR5YoFRZiJJg5apM3aASsZcqpursRMEl3dI2rd8TYHxhJHgES0f3hK8pQ13imoWx
dYULGPujOGQ/Yo0lVNA8lR6L/Z7TZXvfib5tU9jX11d2P3meiMKpHGkcjJZ25JGl
m2WyYxRGlW1wdo5p78YK0b4eS8Fb5FFZRN6A5Fgfe2yk1e8/0Bs9w/TxKa2v9ks7
4aZEqIzWIOOmOYyrOmbDp8J/5o1EEya1HMTYiIz0f1yFrxzp/kotqKfci6xmcbU=
=UCaJ
-----END PGP SIGNATURE-----
--------------enigE1FA6F100C8E3CE763C93D9B--
討論串 (同標題文章)
完整討論串 (本文為第 9 之 9 篇)：