[Bug 791588] Re: no idmapd for nfs4-clients

TJ 791588 at bugs.launchpad.net
Sun Sep 2 15:20:17 UTC 2012


I'm continuing to dig down on this one since it is still biting. The one
thing that is certain is that with the patch applied the error from
rpc.idmapd doesn't appear in the syslog. Here's logging *without* the
patch, using the archive packages.

Working on Precise amd64.

$ apt-cache policy nfs-common
nfs-common:
  Installed: 1:1.2.5-3ubuntu3
  Candidate: 1:1.2.5-3ubuntu3

/etc/fstab contains:

10.254.251.1:/Library /home/all/Library nfs4 _netdev,auto,user 0 0

I wrapped /usr/sbin/rpc.idmapd and blkmapd with shell scripts to capture
their launch and environment at boot time into /var/log/rpc.log

$ cat /var/log/rpc.log
rpc.idmapd  called from parent PID 1
TERM=linux
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
PWD=/
SHLVL=1
UPSTART_INSTANCE=
UPSTART_EVENTS=local-filesystems
UPSTART_JOB=idmapd
PIPEFS_MOUNTPOINT=/run/rpc_pipefs
_=/usr/bin/env


Sep  2 16:01:23 hephaestion rpc.idmapd.real[3869]: libnfsidmap: using domain: lan.eddie.tj
Sep  2 16:01:23 hephaestion rpc.idmapd.real[3869]: libnfsidmap: Realms list: 'LAN.EDDIE.TJ' 
Sep  2 16:01:23 hephaestion rpc.idmapd.real[3869]: libnfsidmap: loaded plugin /lib/libnfsidmap/nsswitch.so for method nsswitch
Sep  2 16:01:23 hephaestion rpc.idmapd.real[3880]: Expiration time is 600 seconds.
Sep  2 16:01:23 hephaestion rpc.idmapd.real[3880]: Opened /proc/net/rpc/nfs4.nametoid/channel
Sep  2 16:01:23 hephaestion rpc.idmapd.real[3880]: Opened /proc/net/rpc/nfs4.idtoname/channel
Sep  2 16:01:23 hephaestion rpc.idmapd.real[3880]: main: open(/var/lib/nfs/rpc_pipefs/nfs): No such file or directory

which confirms the use of the old path.

I ran idmapd with strace to see why it is using that path and found
this:

...
5026  open("/etc/idmapd.conf", O_RDONLY) = 3
...
5026  open("/var/lib/nfs/rpc_pipefs/nfs", O_RDONLY) = -1 ENOENT (No such file or directory)

The idmapd.conf is:

$ cat /etc/idmapd.conf
[General]

Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = lan.eddie.tj

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup


So, "Pipefs-Directory" is the culprit. I don't know when that was set but it is obviously the reason for the issue.

I think the reason that the patched 'blkmapd' solves it is because I
build and install updated packages, and the postinst job changes the
idmapd.conf file.

I found this which seems to indicate a package upgrade issue but I
wasn't notified:

-rw-r--r-- 1 root root 385 Apr 18 10:54 /etc/idmapd.conf.merge-error

[General]

Verbosity = 0
<<<<<<< Current
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = lan.eddie.tj
||||||| Older
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain
=======
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
# Domain = localdomain
>>>>>>> New

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup
/etc/idmapd.conf.merge-error (END)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to nfs-utils in Ubuntu.
https://bugs.launchpad.net/bugs/791588

Title:
  no idmapd for nfs4-clients

Status in “nfs-utils” package in Ubuntu:
  Triaged

Bug description:
  Hello!

  Thought this one is bug-report for nfs-common. (And I really typed
  "ubuntu-bug nfs-common" - I'm innocent! I was redirected!)

  I have a debian nfs-server that uses nfs4 and it isn't possible for
  ubuntu to use nfs4-mounts properly, because idmapd won't start
  although it's configured in /etc/default/nfs-common:

  #######################
  $ cat /etc/default/nfs-common 

  NEED_STATD=
  STATDOPTS=
  NEED_IDMAPD=yes
  NEED_GSSD=

  #######################

  A "ps aux" executed on both server and client shows that on the server rpc.idmapd is running, but on the client side it's not.
  Executing rpc.idmapd on the client manually fails:

  #######################
  $ sudo rpc.idmapd -fv

  rpc.idmapd: libnfsidmap: using domain: localdomain

  rpc.idmapd: libnfsidmap: loaded plugin
  /usr/lib/libnfsidmap/nsswitch.so for method nsswitch

  rpc.idmapd: Expiration time is 600 seconds.
  rpc.idmapd: Opened /proc/net/rpc/nfs4.nametoid/channel
  rpc.idmapd: Opened /proc/net/rpc/nfs4.idtoname/channel
  rpc.idmapd: main: (/var/lib/nfs/rpc_pipefs/nfs): No such file or directory

  #######################

  Easy workaround: create that directory!

  #######################
  $ sudo mkdir /var/lib/nfs/rpc_pipefs/nfs

  #######################

  Unfortunately, this doesn't fix the problem on all ubuntu machines. I
  have three of them: A Powermac G4 with an Ubuntu 11.04 fallback Gnome
  2.x-Desktop, a 64bit-machine as a HTPC with a minimal Ubuntu
  installation running XBMC and a netbook with Unity-Desktop. The first
  two do, the netbook doesn't. Could be a problem with WLAN (the netbook
  is not cable-connected) or the server configuration. Got to check a
  few things here…

  But one thing's clear: As long as the package nfs-common doesn't
  create a /var/lib/nfs/rpc_pipefs/nfs directory, idmapd won't start and
  there is no chance to get nfs4 working properly.

  ProblemType: Bug
  DistroRelease: Ubuntu 11.04
  Package: nfs-common 1:1.2.2-4ubuntu5
  ProcVersionSignature: Ubuntu 2.6.38-9.43-powerpc 2.6.38.4
  Uname: Linux 2.6.38-9-powerpc ppc
  Architecture: powerpc
  Date: Wed Jun  1 21:39:56 2011
  InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release powerpc (20101008)
  ProcEnviron:
   LANGUAGE=de_DE:en
   PATH=(custom, user)
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  SourcePackage: nfs-utils
  UpgradeStatus: Upgraded to natty on 2011-05-03 (28 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/791588/+subscriptions




More information about the foundations-bugs mailing list