Comment 8 for bug 791588

Revision history for this message
Steve Langasek (vorlon) wrote :

On Thu, Jun 02, 2011 at 11:55:49PM -0000, Mitsch wrote:
> > I'm using it this way myself without any trouble.

> If you have already installed nfs-kernel-server on your system, you are
> right: dpkg installs several directories under /var/lib/nfs/rpc_pipefs
> with that package, also the "nfs" directory, needed for idmapd (as
> server AND client). But if you only install nfs-common, idmapd won't
> start until you mkdir /var/lib/nfs/rpc_pipefs/nfs by hand. Promise!

This is certainly not the case. First, the nfs-kernel-server package does
not ship, or create at install time, any files under
/var/lib/nfs/rpc_pipefs. Second, /var/lib/nfs/rpc_pipefs is a kernel
*mount point*, so creating directories under it is pointless; they're
created when mounting the filesystem.

Third, I am using this as I described with no nfs-kernel-server package
installed, and can assure you that idmap has no trouble starting at boot
provided that either NEED_IDMAPD is set in /etc/default/nfs-common, or nfs4
mounts are listed in /etc/fstab.

I don't see anywhere that the bug you describe could be hiding. I'm afraid
it looks like you've misdiagnosed the original symptoms caused by trying to
start rpc.idmapd by hand instead of via the upstart job. As such, I am
closing this bug report as invalid. If you can tell us how to reproduce the
bug step-by-step from a clean install, calling rpc.idmapd via the upstart
job and *not* by hand, please reopen this report providing that information.