Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4
Package: nfs-common
Version: 1:1.2.5-2
Severity: important
After upgrade to nfs-common 1:1.2.5-2 I noticed that uid/gid's are displayed as
'nobody' and 'nogroup' respectively. This is the case checking with both
Nautilus and terminal.
Downgrading to 1:1.2.4-1 from Testing fixes the problem.
I am using Squeeze with nfs-kernel-server version 1:1.2.2-4 on the server side.
Kernel: Linux 3.0.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages nfs-common depends on:
ii adduser 3.113
ii initscripts 2.88dsf-13.11
ii libc6 2.13-21
ii libcap2 1:2.22-1
ii libcomerr2 1.42~WIP-2011-10-05-2
ii libdevmapper1.02.1 2:1.02.65-1
ii libevent-1.4-2 1.4.14b-stable-1
ii libgssapi-krb5-2 1.9.1+dfsg-3
ii libgssglue1 0.3-3.1
ii libk5crypto3 1.9.1+dfsg-3
ii libkeyutils1 1.5.2-2
ii libkrb5-3 1.9.1+dfsg-3
ii libnfsidmap2 0.24-1
ii libtirpc1 0.2.2-5
ii libwrap0 7.6.q-21
ii lsb-base 3.2-28
ii rpcbind 0.2.0-6
ii ucf 3.0025+nmu2
Versions of packages nfs-common recommends:
ii python 2.7.2-9
nfs-common suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111011010903.2848.8166.reportbug@Tramp.hjemmenet tverk">http://lists.debian.org/20111011010903.2848.8166.reportbug@Tramp.hjemmenet tverk
10-17-2011, 12:07 PM
Stephan Windmüller
Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4
> After upgrade to nfs-common 1:1.2.5-2 I noticed that uid/gid's are
> displayed as 'nobody' and 'nogroup' respectively. This is the case
> checking with both Nautilus and terminal. Downgrading to 1:1.2.4-1
> from Testing fixes the problem.
Same problem here, but with 1:1.2.2-4 from squeeze.
- Stephan
10-18-2011, 07:42 AM
Anders Boström
Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4
Hi!
I can confirm this problem with nfs-common 1:1.2.5-2, NFSv4 and
amd64. uid/gid is mapped to nobody/nogroup. Downgrade to 1:1.2.4-1
solves the problem. Running rpc.idmapd with -vvv don't show any errors
or strange messages.
/ Anders
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111018.094245.1143916642825396930.anders@netinsi ght.net">http://lists.debian.org/20111018.094245.1143916642825396930.anders@netinsi ght.net
10-23-2011, 11:49 AM
Jamie Heilman
Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4
Chances are you all have your nfsidmap Domain mismatched between
client and server; check your user.* syslog logs on the client for
messages like: nfsidmap: nss_getpwnam: name 'foo@bar' does not map
into domain 'baz'
The old defaults for rpc.idmapd pre 1:1.2.5-1 didn't make much sense,
(see bug #638607) and now that they've been cleaned up you'll need to
make sure any older servers (particularly Squeeze) are configured to
actually use the correct domain of the system. Usually this can be
accomplished just by commenting out the Domain line in idmapd.conf on
the server, unless your fqdn happens to be funky, in which case you
should just set Domain explicitly.
--
Jamie Heilman http://audible.transient.net/~jamie/
"You came all this way, without saying squat, and now you're trying
to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile?
I liked you better when you weren't saying squat kid." -Buddy
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111023114907.GB2981@cucamonga.audible.transient. net">http://lists.debian.org/20111023114907.GB2981@cucamonga.audible.transient. net
10-23-2011, 04:05 PM
Stephan Windmüller
Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4
On 23.10.2011 13:49, Jamie Heilman wrote:
> Chances are you all have your nfsidmap Domain mismatched between
> client and server; check your user.* syslog logs on the client for
> messages like: nfsidmap: nss_getpwnam: name 'foo@bar' does not map
> into domain 'baz'
In my configuration both domains (client and server) are correctly set,
but this is not the issue: passwd and group data is fetched from ldap as
set in nsswitch.conf, but idmapd does not seem to respect these settings.
- Stephan
10-23-2011, 05:12 PM
"Nils S. Normann"
Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4
Chances are you all have your nfsidmap Domain mismatched between
client and server
That was it! I would never have discovered that without help.
I guess this is part of the charm of running Sid
Thank you!
Nils
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: op.v3td25fpq8pxtt@tramp.hjemmenettverk">http://lists.debian.org/op.v3td25fpq8pxtt@tramp.hjemmenettverk
10-23-2011, 10:58 PM
Jamie Heilman
Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4
Stephan Windmüller wrote:
> On 23.10.2011 13:49, Jamie Heilman wrote:
>
> > Chances are you all have your nfsidmap Domain mismatched between
> > client and server; check your user.* syslog logs on the client for
> > messages like: nfsidmap: nss_getpwnam: name 'foo@bar' does not map
> > into domain 'baz'
>
> In my configuration both domains (client and server) are correctly set,
> but this is not the issue: passwd and group data is fetched from ldap as
> set in nsswitch.conf, but idmapd does not seem to respect these settings.
Then to figure out the issue you face we'll need a good deal more
information about your setup I wager. You say you downgraded to
nfs-common 1.2.2 and it fixed things ... was that on the client, the
server, or both? You're using ldap, how do you have libnfsidmap
configured? (/etc/idmapd.conf particularly the Method setting from
the [Translation] section, and if you're using the umich schema plugin
then the settings of that section too) Looking at your ldap server
logs, are the lookups related to the translation quereies even making
to the server? Have you tried to strace rpc.idmapd to determine what
values it's using during the lookups? Were your kernels built with
CONFIG_NFS_USE_NEW_IDMAPPER=y or not (I'd guess not given that 1.2.2
didn't even ship with the nfsidmap so there's nothing for request-key
to call in squeeze)?
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111023225808.GB2766@cucamonga.audible.transient. net">http://lists.debian.org/20111023225808.GB2766@cucamonga.audible.transient. net
10-24-2011, 08:21 AM
Stephan Windmüller
Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 24.10.2011 00:58, Jamie Heilman wrote:
>> In my configuration both domains (client and server) are
>> correctly set, but this is not the issue: passwd and group data
>> is fetched from ldap as set in nsswitch.conf, but idmapd does not
>> seem to respect these settings.
> Then to figure out the issue you face we'll need a good deal more
> information about your setup I wager. You say you downgraded to
> nfs-common 1.2.2 and it fixed things ...
No, the client is running squeeze so 1.2.2 was the only version I used.
> was that on the client, the server, or both?
The server is running Solaris 10.
> You're using ldap, how do you have libnfsidmap configured?
The [Translation] section has one entry:
Method = nsswitch
> Looking at your ldap server logs, are the lookups related to the
> translation quereies even making to the server?
Not if I am using idmapd. If I disable it, the server gets the following
queries:
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EA5200F.9020204@white-hawk.de">http://lists.debian.org/4EA5200F.9020204@white-hawk.de
10-24-2011, 10:39 AM
Anders Boström
Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4
>>>>> "SW" == Stephan Windmüller <windy@white-hawk.de> writes:
SW> On 23.10.2011 13:49, Jamie Heilman wrote:
>> Chances are you all have your nfsidmap Domain mismatched between
>> client and server; check your user.* syslog logs on the client for
>> messages like: nfsidmap: nss_getpwnam: name 'foo@bar' does not map
>> into domain 'baz'
SW> In my configuration both domains (client and server) are correctly set,
SW> but this is not the issue: passwd and group data is fetched from ldap as
SW> set in nsswitch.conf, but idmapd does not seem to respect these settings.
And in my configuration, both domains (client and server) are also
correctly set. And the only messages from nfsidmap in syslog is a
message stating that the correct domain is used. In my case, NIS is
used for passwd and group data.
The server is using nfs-common 1:1.2.2-4 . Switching back to 1:1.2.4-1
on the client solves the problem.
/ Anders
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111024.123924.1560985971554820485.anders@netinsi ght.net">http://lists.debian.org/20111024.123924.1560985971554820485.anders@netinsi ght.net
10-30-2011, 06:59 PM
Jamie Heilman
Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4
Stephan Windmüller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 24.10.2011 00:58, Jamie Heilman wrote:
>
> >> In my configuration both domains (client and server) are
> >> correctly set, but this is not the issue: passwd and group data
> >> is fetched from ldap as set in nsswitch.conf, but idmapd does not
> >> seem to respect these settings.
> > Then to figure out the issue you face we'll need a good deal more
> > information about your setup I wager. You say you downgraded to
> > nfs-common 1.2.2 and it fixed things ...
>
> No, the client is running squeeze so 1.2.2 was the only version I used.
OK, this should arguably be a different bug report then as your issue
doesn't appear to be a post-stable regression.
> > Have you tried to strace rpc.idmapd to determine what values it's
> > using during the lookups?
>
> No, I did not try that.
It may be worth trying. Here's what I see stracing my (working)
rpc.idmapd on a Debian 6 nfs4 client (nfs-common 1:1.2.2-4) talking to
a Debian Sid server: