Package: nfs-common
Version: 1:1.2.8-9
Severity: important
Dear Maintainer,
I'm reporting this bug in nfs (4)? where client's uid's/gid's are shown as
them instead of their regular ownerships. This has been puzzling me for over
a month now. The problem appeared after a system upgrade in jessie. Before
this update everything worked well.
More details are below.
Problem description:
We (a school) serve home directories over nfs from a wheezy system.
The clients mount them using nfs v4.
Some client systems were upgraded to jessie. On jessie systems, nfs v4
clients worked ok, until some day (about half of july) systemd, a new
libc6 and a new kernel appeared.
Since then, identities of the users home directories are shown as
4294967294.
When the main login directory has the right identities, subdirectories and
files within it still can have the 4294967294 for uid and gid.
This bahaviour is consistent on all the jessie systems I upgraded.
And yes, identities for the users, as shown with id, _are_ available in
all cases.
When booting, I see that systemd registers the id_resolver in the kernel,
as well as the id_legacy resolver.
Since the id_resolver is supposed to call nfsidmap, I raised Verbosity in
/etc/idmapd.conf to 65535.
This shows that nfsidmap is simply not called for some users,
some random, some rather consistent. About a third is lacking a call.
When a user lookup is succesful, the corresponding group is looked up as
well.
From time to time users, whether logged in or not, lose their identities.
This can be inidivdual files or directories. Lateron all identities are
present again.
I see no request-key program, it looks like systemd performs this role.
I've been debugging a lot, and still have no clue who is actually calling
the id_resolver (as defined in /etc/request-key.d/id_resolver.conf).
When I remove the file, _all_ users and groups immediately show up as
4294967294. I have no idea what happens when the nfsidmap key expires
after 600 seconds, tracing listings show that "known" users stay known,
and some of the unknown ones become known over time.
System setup:
The nfs server is an up-to-date wheezy system.
The partition with the home directory is an xfs partition.
The export entry looks like:
client(rw,secure,no_subtree_check,sync)
The mount option on the client looks like:
nfs rw,vers=4,proto=tcp,rsize=524288,wsize=524288,nosuid,nodev,noatime
There is no gss setup here.
Identities are distributed through nis.
Identities on the clients (as shown by id) are always avalable.
Ideas:
The problem suggests something is in the way. This might be the rpc.idmap
daemon. Killing it did not resolve the problem.
Bug #744768 might be related, although I don't see the (null) so often.
Maybe there is some 32-bit/16-bit uid/gid mixup.
Tested if uid/gid's of the users correspond to some kind of a pattern. No,
these are just in-between other users. Same for permissions
nfv4 patches in kernel 3.14.11 (in jessie from 3.14.12)?
looks like bug #562821, but we're talking clients instead of server.
Debugging:
I'm willing to help debugging this, but I'm out of options.
* What led up to the situation?
An regular upgrade in jessie about half of july 2014
* What exactly did you do (or not do) that was effective (or
ineffective)?
aptitude update, which pulled in kernel 3.14.12, systemd for the first
time, and libc6 2.19.9? Problem has also been reproduced on older libc6's
* What was the outcome of this action?
uid's/gid's did show up as 4294967294 instead; id lists id's correctly
* What outcome did you expect instead?
user directories with user id'a and group id's shown correctly
Thanks,
Piet
-- Package-specific info:
-- rpcinfo --
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100007 2 udp 37063 ypbind
100007 1 udp 37063 ypbind
100007 2 tcp 48220 ypbind
100007 1 tcp 48220 ypbind
100024 1 udp 60043 status
100024 1 tcp 45346 status
-- /etc/default/nfs-common --
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=
-- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
[Translation]
Method = nsswitch
-- /etc/fstab --
# nfshost
nfshost:/homes /homes nfs4
rw,vers=4,proto=tcp,rsize=524288,wsize=524288,nosuid,nodev,noatime 0 0
-- /proc/mounts --
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-2-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages nfs-common depends on:
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-53.3
ii libc6 2.19-9
ii libcap2 1:2.24-4
ii libcomerr2 1.42.11-2
ii libdevmapper1.02.1 2:1.02.85-2
ii libevent-2.0-5 2.0.21-stable-1
ii libgssapi-krb5-2 1.12.1+dfsg-7
ii libk5crypto3 1.12.1+dfsg-7
ii libkeyutils1 1.5.9-5
ii libkrb5-3 1.12.1+dfsg-7
ii libmount1 2.20.1-5.8
ii libnfsidmap2 0.25-5
ii libtirpc1 0.2.4-2.1
ii libwrap0 7.6.q-25
ii lsb-base 4.1+Debian13
ii rpcbind 0.2.1-4
ii ucf 3.0030
Versions of packages nfs-common recommends:
ii python 2.7.8-1
Versions of packages nfs-common suggests:
pn open-iscsi <none>
pn watchdog <none>
-- no debconf information
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20140822100652.2288.29115.report...@asterix.bin
