Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4
JH == Jamie Heilman ja...@audible.transient.net writes: JH Anders Boström wrote: SW == Stephan Windmüller wi...@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' Sorry for the late respons... I've got time to test this again, and it is indeed a domain-problem. However, I don't get any nfsidmap-messages in the client syslog, but I do in the server. If I reconfigure my client idmapd.conf to 'Domain = localdomain' it works as expected. If I use the default idmapd.conf from nfs-common 1:1.2.5-2+b1 it does not work. The server is in this case using the default idmapd.conf from nfs-common 1:1.2.2-4. And doing any change on the server regarding the domain-configuration will break a lot of clients, all running NFSv4 using Debian stable, Ubuntu etc. Soo it is a no-go. Also I don't understand how I'm supposed to configure this. I have another client in another domain. It is supposed to mount NFS from it's own domain *and* from our server. If 'Domain = localdomain' is configured in all places, it works, but I how is this supposed to be configured??? / Anders -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4
Anders Boström wrote: Sorry for the late respons... I've got time to test this again, and it is indeed a domain-problem. However, I don't get any nfsidmap-messages in the client syslog, but I do in the server. If I reconfigure my client idmapd.conf to 'Domain = localdomain' it works as expected. If I use the default idmapd.conf from nfs-common 1:1.2.5-2+b1 it does not work. The server is in this case using the default idmapd.conf from nfs-common 1:1.2.2-4. And doing any change on the server regarding the domain-configuration will break a lot of clients, all running NFSv4 using Debian stable, Ubuntu etc. Soo it is a no-go. Also I don't understand how I'm supposed to configure this. I have another client in another domain. It is supposed to mount NFS from it's own domain *and* from our server. If 'Domain = localdomain' is configured in all places, it works, but I how is this supposed to be configured??? No, unfortunately, Domain = localdomain was just bad default that got shipped. Your server and its working clients are currently relying on what is essentially a misconfiguration. Domain should be set to your NFSv4 Domain Name. See RFC3530 section 5.8, or RFC5661 section 5.9. Multi-domain NFSv4 is still in draft: http://tools.ietf.org/html/draft-adamson-nfsv4-multi-domain-access-04 -- Jamie Heilman http://audible.transient.net/~jamie/ ...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity... -Rimmer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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:
[67]canarsie~/sudo ls -l /proc/1497/fd
total 0
lrwx-- 1 root root 64 Oct 30 19:08 0 - /dev/null
lrwx-- 1 root root 64 Oct 30 19:08 1 - /dev/null
lrwx-- 1 root root 64 Oct 30 19:08 11 - socket:[17299]
lrwx-- 1 root root 64 Oct 30 19:08 2 - /dev/null
lrwx-- 1 root root 64 Oct 30 19:08 3 - anon_inode:[eventpoll]
lrwx-- 1 root root 64 Oct 30 19:08 5 - socket:[1723]
lrwx-- 1 root root 64 Oct 30 19:08 6 - socket:[1724]
lrwx-- 1 root root 64 Oct 30 19:08 7 -
/proc/1497/net/rpc/nfs4.nametoid/channel
lrwx-- 1 root root 64 Oct 30 19:08 8 -
/proc/1497/net/rpc/nfs4.idtoname/channel
lr-x-- 1 root root 64 Oct 30 19:08 9 - /var/lib/nfs/rpc_pipefs/nfs
[68]canarsie~/sudo strace -s 50 -f -p 1497
...
epoll_wait(3, 805afc0, 32, -1) = -1 EINTR (Interrupted system call)
--- SIGUSR1 (User defined signal 1) @ 0 (0) ---
send(5, a, 1, 0) = 1
sigreturn() = ? (mask now [])
clock_gettime(CLOCK_MONOTONIC, {296845, 413152888}) = 0
open(/var/lib/nfs/rpc_pipefs/nfs,
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
getdents(4, /* 3 entries */, 32768) = 52
getdents(4, /* 0 entries */, 32768) = 0
close(4)= 0
open(/var/lib/nfs/rpc_pipefs/nfs/clnt29, O_RDONLY) = 4
open(/var/lib/nfs/rpc_pipefs/nfs/clnt29/idmap, O_RDWR) = -1 ENOENT (No such
file or directory)
fcntl64(4, F_SETSIG, 0xc) = 0
fcntl64(4, F_NOTIFY, DN_CREATE|DN_DELETE|DN_MULTISHOT) = 0
epoll_wait(3, {{EPOLLIN, {u32=6, u64=6}}}, 32, -1) = 1
clock_gettime(CLOCK_MONOTONIC, {296845, 416977043}) = 0
recv(6, a, 1, 0) = 1
epoll_wait(3, 805afc0, 32, -1) = -1 EINTR (Interrupted system call)
--- SIGUSR2 (User defined signal 2) @ 0 (0) ---
send(5, a, 1, 0) = 1
sigreturn() = ? (mask now [])
clock_gettime(CLOCK_MONOTONIC, {296845, 420593293}) = 0
open(/var/lib/nfs/rpc_pipefs/nfs/clnt29/idmap, O_RDWR) = 10
epoll_ctl(3, EPOLL_CTL_ADD, 10, {EPOLLIN, {u32=10, u64=10}}) = 0
fcntl64(4, F_SETSIG, 0) = 0
fcntl64(4, F_NOTIFY, 0) = 0
epoll_wait(3, {{EPOLLIN, {u32=6, u64=6}}}, 32, -1) = 1
clock_gettime(CLOCK_MONOTONIC, {296845, 421892590}) = 0
recv(6, a, 1, 0) = 1
epoll_wait(3, 805afc0, 32, -1) = -1 EINTR (Interrupted system call)
--- SIGUSR1 (User defined signal 1) @ 0 (0) ---
send(5, a, 1, 0) = 1
sigreturn() = ? (mask now [])
clock_gettime(CLOCK_MONOTONIC, {296845, 424126540}) = 0
open(/var/lib/nfs/rpc_pipefs/nfs,
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 12
getdents(12, /* 4 entries */, 32768)= 72
getdents(12, /* 0 entries */, 32768)= 0
close(12) = 0
open(/var/lib/nfs/rpc_pipefs/nfs/clnt2a, O_RDONLY) = 12
open(/var/lib/nfs/rpc_pipefs/nfs/clnt2a/idmap, O_RDWR) = -1 ENOENT (No such
file or directory)
fcntl64(12, F_SETSIG, 0xc) = 0
fcntl64(12, F_NOTIFY, DN_CREATE|DN_DELETE|DN_MULTISHOT) = 0
epoll_wait(3, {{EPOLLIN, {u32=10, u64=10}}, {EPOLLIN, {u32=6, u64=6}}}, 32, -1)
= 2
clock_gettime(CLOCK_MONOTONIC, {296845, 426810897}) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 10, {EPOLLIN, {u32=10, u64=10}}) = 0
read(10,
\0\1r...@audible.transient.net\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
140) = 140
open(/etc/passwd, O_RDONLY|O_CLOEXEC) = 13
fstat64(13, {st_mode=S_IFREG|0644, st_size=1717, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb772f000
read(13, root:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemo..., 4096) = 1717
close(13) = 0
munmap(0xb772f000, 4096)= 0
write(10,
\0\1r...@audible.transient.net\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
140) = 140
epoll_ctl(3, EPOLL_CTL_ADD, 10, {EPOLLIN, {u32=10, u64=10}}) = 0
recv(6, a, 1, 0) = 1
epoll_wait(3, {{EPOLLIN, {u32=10, u64=10}}}, 32, -1) = 1
Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4
Anders Boström wrote: SW == Stephan Windmüller wi...@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. In theory setting Verbosity to 4 in idmapd.conf and comparing the logged results between 1:1.2.4-1 and 1:1.2.5-2 should help identify the regression. In practice, it might require deeper introspection. Is your client kernel configured with NFS_USE_NEW_IDMAPPER? If so, setting Verbosity to 4 on the client probably won't help (still potentially useful on the server though). What you can do is configure a simple wrapper for nfsidmap and configure that to be called in request-key.conf. Maybe something like: #!/bin/sh echo $0 $@ | /usr/bin/logger -p local0.debug exec /usr/sbin/nfsidmap $@ Then atleast you can keep track of what the client is looking up. OTOH, if you're not using a kernel with NFS_USE_NEW_IDMAPPER set, setting Verbosity to 4 in idmapd.conf should help spot the difference. -- Jamie Heilman http://audible.transient.net/~jamie/ I was in love once -- a Sinclair ZX-81. People said, No, Holly, she's not for you. She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway. -Holly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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: - - fd=31 ACCEPT from IP=[...] (IP=0.0.0.0:389) op=0 BIND dn= method=128 op=0 RESULT tag=97 err=0 text= op=1 SRCH base=[...] scope=2 deref=0 filter=((objectClass=posixAccount)(uidNumber=-2)) op=1 SRCH attr=userPassword cn gidNumber uidNumber loginShell objectClass gecos uid homeDirectory op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= fd=32 ACCEPT from IP=[...] (IP=0.0.0.0:389) op=0 BIND dn= method=128 op=0 RESULT tag=97 err=0 text= op=1 SRCH base=[...] scope=2 deref=0 filter=((objectClass=posixGroup)(gidNumber=-2)) op=1 SRCH attr=cn userPassword memberUid gidNumber uniqueMember op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= - - What seems odd here is the -2 for uid and gid. An ls on the client shows 4294967294 for both values (it's a 64bit client). When I enable idmapd, in /etc/default/nfs-common there are no queries like the above. Have you tried to strace rpc.idmapd to determine what values it's using during the lookups? No, I did not try that. Were your kernels built with CONFIG_NFS_USE_NEW_IDMAPPER=y It is the standard kernel of squeeze (2.6.32-5-amd64) and according to the config file this option does not exist. Regards Stephan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6lIA8ACgkQi8rkj8W4fFV/IQCfb78Jy6rSJKNP6YyVyo4Z//6s 7rEAoI4Csz7g+xr/6ubaVh4XrUkBvQlw =qFuv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644948: nfs-common: Wrong uid/gid with latest version using NFSv4
SW == Stephan Windmüller wi...@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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 signature.asc Description: OpenPGP digital signature
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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)? -- Jamie Heilman http://audible.transient.net/~jamie/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 signature.asc Description: OpenPGP digital signature
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. -- Package-specific info: -- rpcinfo -- program vers proto port 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 1000241 udp 45260 status 1000241 tcp 50813 status -- /etc/default/nfs-common -- NEED_STATD= STATDOPTS= NEED_IDMAPD=yes NEED_GSSD= -- /etc/idmapd.conf -- [General] Verbosity = 0 Pipefs-Directory = /var/lib/nfs/rpc_pipefs [Mapping] Nobody-User = nobody Nobody-Group = nogroup -- /etc/fstab -- -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) 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-21.9.1+dfsg-3 ii libgssglue1 0.3-3.1 ii libk5crypto31.9.1+dfsg-3 ii libkeyutils11.5.2-2 ii libkrb5-3 1.9.1+dfsg-3 ii libnfsidmap20.24-1 ii libtirpc1 0.2.2-5 ii libwrap07.6.q-21 ii lsb-base3.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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
