Red Hat Bugzilla – Full Text Bug Listing
|Summary:||rpc.idmapd not started on client|
|Product:||[Fedora] Fedora||Reporter:||Richard W.M. Jones <rjones>|
|Component:||nfs-utils||Assignee:||Steve Dickson <steved>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||17||CC:||bfields, jlayton, ndevos, sexynaya2010, steved|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-05-17 16:43:02 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Richard W.M. Jones 2012-04-27 09:50:07 EDT
Description of problem: rpc.idmapd is required to get nfsv4 to work usefully. It should be running on *both* the client and server. However on Fedora 17 it is not started on the client side. I had to write an rc.local script to start it by hand: #!/bin/bash - # Fix NFS. sleep 10 systemctl start var-lib-nfs-rpc_pipefs.mount /usr/sbin/rpc.idmapd Note: (1) sleep 10 is needed because rc.local runs too early. (2) /var/lib/nfs/rpc_pipefs is not mounted even though the mountpoint and service exists. No idea why. I tried setting NEED_IDMAPD=yes in /etc/default/nfs and /etc/default/nfs-common, but neither made any difference. Version-Release number of selected component (if applicable): nfs-utils-1.2.5-12.fc17.armv7hl
Comment 1 Dirk Cummings 2012-05-09 19:30:58 EDT
The workaround I've been using is systemctl enable nfs-server.service on the client. I only need the client to be the "client" but that service starts idmapd so meh
Comment 2 Steve Dickson 2012-05-12 07:37:13 EDT
What kernel version are you using? With 3.3 and beyond the idmapped was changed to use a keyring based idmapping using the nfsidmap command. See nfsidmap(5) for details. With the being the cause the rpc.idmapd daemon no longer needed to be started on the NFS client.
Comment 3 Richard W.M. Jones 2012-05-12 08:22:37 EDT
Interesting ... This is arm, so it was: Linux trim.home.annexia.org 188.8.131.52-1.0.arm1.y1.armv7hl.tegra #1 SMP PREEMPT Fri Jan 20 11:31:29 EST 2012 armv7l armv7l armv7l GNU/Linux because there *was* a problem booting this hardware with the newer kernel. Since (even) newer kernels are available I need to try those. I'll try to reboot this machine later today (currently it's running some crucial builds).
Comment 4 Richard W.M. Jones 2012-05-17 16:43:02 EDT
Yes, confirmed that this does work with the later kernel.