Description of problem: trying to start nfs-idmapd.service (or nfs-idmap.service) reports that: Job for nfs-idmapd.service failed. See "systemctl status nfs-idmapd.service" and "journalctl -xe" for details. and then # systemctl status nfs-idmapd.service -l ● nfs-idmapd.service - NFSv4 ID-name mapping service Loaded: loaded (/usr/lib/systemd/system/nfs-idmapd.service; static) Active: failed (Result: exit-code) since Thu 2014-10-30 22:17:18 AEDT; 20s ago Process: 4589 ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS (code=exited, status=127) Oct 30 22:17:18 localhost.localdomain rpc.idmapd[4589]: /usr/sbin/rpc.idmapd: symbol lookup error: /usr/sbin/rpc.idmapd: undefined symbol: strlcpy Oct 30 22:17:18 localhost.localdomain systemd[1]: nfs-idmapd.service: control process exited, code=exited status=127 Oct 30 22:17:18 localhost.localdomain systemd[1]: Failed to start NFSv4 ID-name mapping service. Oct 30 22:17:18 localhost.localdomain systemd[1]: Unit nfs-idmapd.service entered failed state. Oct 30 22:17:18 localhost.localdomain systemd[1]: nfs-idmapd.service failed. Version-Release number of selected component (if applicable): nfs-utils-1:1.3.1-1.1.fc21.x86_64 How reproducible: I've only got two systems running f21alpha, but both have the issue. Steps to Reproduce: 1. install nfs-utils 2. run 'systemctl start nfs-idmap[d].service Actual results: Fails to start Expected results: Starts Additional info:
I'll second the above comments. Same situation here on my Fedora 21 installation. Same errors on startup, same status output. nfs-utils-1.3.1-1.1.fc21.x86_64 I can access my NFS shares but any time I do I get a notification stating "a problem in the nfs-utils-1.3.1-1.1.fc21.x86_64 package has been detected". I've seen this notice hundreds of times. Additionally, the GID and UID of the files and folders is incorrect. For example: ls /mnt/script -rwxrwxr-x. 1 4294967294 4294967294 1099 Nov 1 05:58 centos_webmin.sh drwxr-xr-x. 2 4294967294 4294967294 4096 Sep 28 03:33 compaq_temp drwxrwxr-x. 2 4294967294 4294967294 4096 Nov 2 04:06 conky drwxrwxr-x. 2 4294967294 4294967294 4096 Sep 8 03:05 cronjobs drwxrwxr-x. 2 4294967294 4294967294 4096 Jan 19 2014 grub_scripts drwxrwxr-x. 2 4294967294 4294967294 12288 Oct 29 04:51 junk_yard drwxrwxr-x. 2 4294967294 4294967294 4096 Oct 16 03:50 media_scripts drwxrwxr-x. 2 4294967294 4294967294 4096 Oct 27 05:40 moin_scripts drwxrwxr-x. 13 4294967294 4294967294 4096 Sep 26 08:21 os drwxrwxr-x. 2 4294967294 4294967294 4096 Jun 18 05:59 python drwxrwxr-x. 2 4294967294 4294967294 4096 Sep 1 05:31 release drwxrwxr-x. 2 4294967294 4294967294 4096 Sep 29 12:39 screenshots -r--r--r--. 1 4294967294 4294967294 121764 Nov 1 06:36 system-config-firewall-1.2.27-5.el6.noarch.rpm -r--r--r--. 1 4294967294 4294967294 427852 Nov 1 06:39 system-config-firewall-base-1.2.27-5.el6.noarch.rpm -r--r--r--. 1 4294967294 4294967294 38264 Nov 1 06:36 system-config-firewall-tui-1.2.27-5.el6.noarch.rpm drwxrwxr-x. 2 4294967294 4294967294 4096 Aug 19 2013 text drwxrwxr-x. 2 4294967294 4294967294 4096 Oct 29 03:58 tool-crib
I'm not at school today to be 100% sure but those uid.god numbers look identical to what I was seeing. Mine should all be in the 10000 - 17000 range.
Hmm...odd. I see this on my (fully up-to-date) F21 machine as well. glibc just recently added strlcpy. It looks like nfs-utils was built against a version of glibc that provided that symbol, but the version of glibc in the repos does not. I'm not sure how that would happen. One possibility: f21 had a previous version of glibc that provided this symbol, but the current one doesn't, and nfs-utils was built against the older version. Steve, it might be worth bumping the "release" and doing a rebuild of nfs-utils to see if that fixes this? Or maybe chat with the folks maintaining glibc to see if they have insight into what went wrong?
(In reply to Jeff Layton from comment #3) > > Steve, it might be worth bumping the "release" and doing a rebuild of > nfs-utils to see if that fixes this? Or maybe chat with the folks > maintaining glibc to see if they have insight into what went wrong? The Rawhide build: http://koji.fedoraproject.org/koji/taskinfo?taskID=8026296 The F21 build: http://koji.fedoraproject.org/koji/taskinfo?taskID=8026326 Let's see what happens....
(In reply to Steve Dickson from comment #4) > (In reply to Jeff Layton from comment #3) > > > > Steve, it might be worth bumping the "release" and doing a rebuild of > > nfs-utils to see if that fixes this? Or maybe chat with the folks > > maintaining glibc to see if they have insight into what went wrong? > > The Rawhide build: > http://koji.fedoraproject.org/koji/taskinfo?taskID=8026296 > > The F21 build: > http://koji.fedoraproject.org/koji/taskinfo?taskID=8026326 > > Let's see what happens.... They both built cleanly but the same undefined symbol: strlcpy happens as in bz 1159943. yum downgrading libnfsidmap to 0.26-0.1 does fix the problem so its definitely a libnfsidmap problem... I'm going to dup this bz as bz 1159943 *** This bug has been marked as a duplicate of bug 1159943 ***