I seem to be getting similar errors during the installation of nfs-common (and nfs-kernel-server for that matter) inside a Debian Jessie LXC container:
Creating config file /etc/idmapd.conf with new version
Job for nfs-common.service failed. See 'systemctl status nfs-common.service' and 'journalctl -xn' for details.
invoke-rc.d: initscript nfs-common, action "start" failed.
dpkg: error processing package nfs-common (--configure):
subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin (2.19-18+deb8u6) ...
Processing triggers for systemd (215-17+deb8u5) ...
Errors were encountered while processing:
nfs-common
E: Sub-process /usr/bin/dpkg returned an error code (1)
The command systemctl status nfs-common.service prints:
ā nfs-common.service - LSB: NFS support files common to client and server
Loaded: loaded (/etc/init.d/nfs-common)
Active: failed (Result: exit-code) since Thu 2016-12-29 13:59:22 UTC; 2min 18s ago
Dec 29 13:59:22 testserv rpc.idmapd[2506]: main: fcntl(/run/rpc_pipefs/nfs): Invalid argument
Dec 29 13:59:22 testserv nfs-common[2495]: Starting NFS common utilities: statd idmapd failed!
Dec 29 13:59:22 testserv systemd[1]: nfs-common.service: control process exited, code=exited status=1
Dec 29 13:59:22 testserv systemd[1]: Failed to start LSB: NFS support files common to client and server.
Dec 29 13:59:22 testserv systemd[1]: Unit nfs-common.service entered failed state.
The command journalctl -xn prints:
-- Logs begin at Thu 2016-12-29 13:13:37 UTC, end at Thu 2016-12-29 13:59:23 UTC. --
Dec 29 13:59:06 testserv systemd[1]: Reloading.
Dec 29 13:59:21 testserv systemd[1]: Reloading.
Dec 29 13:59:22 testserv systemd[1]: Reloading.
Dec 29 13:59:22 testserv systemd[1]: Starting LSB: NFS support files common to client and server...
-- Subject: Unit nfs-common.service has begun with start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit nfs-common.service has begun starting up.
Dec 29 13:59:22 testserv rpc.idmapd[2506]: main: fcntl(/run/rpc_pipefs/nfs): Invalid argument
Dec 29 13:59:22 testserv nfs-common[2495]: Starting NFS common utilities: statd idmapd failed!
Dec 29 13:59:22 testserv systemd[1]: nfs-common.service: control process exited, code=exited status=1
Dec 29 13:59:22 testserv systemd[1]: Failed to start LSB: NFS support files common to client and server.
-- Subject: Unit nfs-common.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit nfs-common.service has failed.
--
-- The result is failed.
Dec 29 13:59:22 testserv systemd[1]: Unit nfs-common.service entered failed state.
Dec 29 13:59:23 testserv systemd[1]: Reloading.
I tried with a container build from an Ubuntu template, and that one had no problem installing nfs-common. That leaves us with the question; why it does not work on Debianā¦
When I edit /etc/default/nfs-common to change: NEED_IDMAPD= into NEED_IDMAPD=no (after installation)
I can start nfs-common (and even apt-get upgrade nfs-common) flawlessly. But now I may face an id-mapping issue laterā¦
In my efforts to not workaround, but find the root cause instead Iām currently investigating (from the logs posted above): rpc.idmapd[2506]: main: fcntl(/run/rpc_pipefs/nfs): Invalid argument, which seems to start the cascading issue. I did find a post about a kernel issue, but this would be strange as it does work in my Ubuntu container (running on the same stock Omnia kernel)ā¦
In short: I am lostā¦ Maybe @miska, who has helped me a lot in domain of LXC on Omnia in the passed, has a pointer for me here. Could you maybe try to replicate (simply create a container from the Jessie template, and install nfs-common)?
I donāt have Debian but I speculate there is a problem in the startup scripts that they donāt mount /run/rpc_pipefs/nfs for rpc.idmapd. Based on CentOS 7 it should have a mount like this:
Feels like a bug in the template (or something in that vein), as it does not occur in any other Debian instances I have running, nor does it occur when I use the Omniaās supplied Ubuntu template. My best guess is that it has to do with the (initd) āupstartā order in the container.
Very sad (for me) as the Omnia was supposed to act like a backup-server (through Debian LXC).
Anyone know the person āresponsibleā for the Debian template (I think/hope it should/could be fixed there).
@Miska, @AdminX, @Tomnia, @Etz, @Bernstein, You guys have helped me with (LXC) related stuff before; care to shine your light over this?
Should I wait until the template is adapted so that nfs-common works out of the box, should I keep digging deeper for a solution (I fear that it would be in vain), or should I simply switch to an Ubuntu container (that atm. does not seem to include this issue)?
Edit: am setting up an Ubuntu version as we āspeakā.
Iām shooting for the latterā¦ as I am hoping that the Debian template-owner will pick this up (fix should be pretty straight forward I think). Albeit people are being el-noncommunicado about this one.
Edit: NFS3 seems to work for me now (but Iām still curious what is wrong here).
Without idmapd the NFS4 mounts do not work at all (they need idmapd running)
Search on web shows that the same happened to other people on various distributions when they did not have dnotify support in kernel. The container uses kernel from TurrisOS of courseā¦ and it seems that dnotify support is not turned on there (I just guess it, based on missing /proc/sys/fs/dir-notify-enable in both TurrisOS and container).
