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.
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 nfs/rpc_ pipefs nfs/rpc_ pipefs/ nfs by hand. Promise!
> right: dpkg installs several directories under /var/lib/
> 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/
This is certainly not the case. First, the nfs-kernel-server package does nfs/rpc_ pipefs. Second, /var/lib/ nfs/rpc_ pipefs is a kernel
not ship, or create at install time, any files under
/var/lib/
*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 nfs-common, or nfs4
installed, and can assure you that idmap has no trouble starting at boot
provided that either NEED_IDMAPD is set in /etc/default/
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.