idmapd not started when booting under systemd

Patch sent to upstream ML, I'll send the link here once http://www.spinics.net/lists/linux-nfs/ has it.

This bug was fixed in the package nfs-utils - 1:1.2.8-9ubuntu5

---------------
nfs-utils (1:1.2.8-9ubuntu5) vivid; urgency=medium

  * Add 27-systemd-start-nfs-idmapd-also-on-clients.patch: idmapd is needed
    for clients too, so start it from nfs-client.target and stop binding to it
    in nfs-server.service. (LP: #1428961)
 -- Martin Pitt <email address hidden> Fri, 06 Mar 2015 11:56:46 +0100

Upstream report: http://www.spinics.net/lists/linux-nfs/msg49991.html . Upstream says that with newer versions this isn't necessary any more?

This doesn't seem to be fixed. I have two computers with up to date packages running nfs+kerberos+sssd and there is no idmap service and all my mounted stuff comes with those endlessly long ids indicating the idmapping didn't work. -> Thus. Not fixed, not working, idmapd still required on the client.

Jacqueline, can you confirm that the output of this command matches on your affected system?

$ cat /etc/request-key.d/id_resolver.conf
create id_resolver * * /usr/sbin/nfsidmap -t 600 %k %d

Also, do you have the keyutils package installed? If not, does installing it fix the problem you're seeing?

It's possible that the problem here is because I failed to notice keyutls was not a dependency of the NFS stack.

Hi Steve,

indeed the package keyutils was missing and now it works as it should - thank you!

Ok, thanks for confirming. Opened bug #1449074 to get this dependency fixed in vivid.

Please don't kill me if I was supposed to create a new bug report rather than update this one.

This bug is still present in Ubuntu 15.10 (Wily Werewolf).

My Ubuntu NFS client is working fine, apart from the fact that no idmapd is running.

# pgrep idmap
#

# dpkg-query -W nfs-common
nfs-common 1:1.2.8-9ubuntu10

# systemctl status nfs-idmapd
● nfs-idmapd.service - NFSv4 ID-name mapping service
   Loaded: loaded (/lib/systemd/system/nfs-idmapd.service; static; vendor preset: enabled)
   Active: inactive (dead)

# systemctl start nfs-idmapd
Failed to start nfs-idmapd.service: Unit nfs-server.service failed to load: No such file or directory.

I don't have nfs-kernel-server package installed and the dependency is still present in /lib/systemd/system/nfs-idmapd.service file

# grep BindsTo /lib/systemd/system/nfs-idmapd.service
BindsTo=nfs-server.service

I have one more remark in http://www.spinics.net/lists/linux-nfs/msg49996.html Steve mentions that you want to use nfsidmap, however the nfs-idmapd.service unit file starts rpc.idmapd.

# grep ExecStart /lib/systemd/system/nfs-idmapd.service
ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS

It looks like the current set-up in Ubuntu 15.10 where rpc.idmapd daemon is started on the server only may be correct/intentional after all. I did not find conclusive information, however this BSD idmapd man page http://man7.org/linux/man-pages/man8/idmapd.8.html states:

"Note that on more recent kernels only the NFSv4 server uses rpc.idmapd.
The NFSv4 client instead uses nfsidmap(8), and only falls back to
rpc.idmapd if there was a problem running the nfsidmap(8) program."

Which seems to be intended solution in Ubuntu. In any case current systemd configuration is a bit confusing. There are two idmap unit files:

$ systemctl -a list-unit-files *idmap*
UNIT FILE STATE
idmapd.service masked
nfs-idmapd.service static

Normally one would expect that: idmapd.service starts rpc.idmapd (instead this file is masked) and nfs-idmapd.service starts nfsidmap (instead it starts rpc.idmapd). Of course the latter only before realizing that nfsidmap is not a daemon and it does not need a unit file.

I was able to get NFS4 to correctly map user names in Ubuntu 15.10 after updating /etc/idmapd.conf to explicitly define Domain parameter. Assuming my computer FQDN is nfsclient.lan I had to set:
# set your own domain here, if id differs from FQDN minus hostname
Domain = lan

In case one has a correctly configured DNS server this should apparently work out of the box with an implicit default setting; idmapd.conf man page states:
       Domain The local NFSv4 domain name. An NFSv4 domain is a namespace with a unique username<->UID and group‐
              name<->GID mapping. (Default: Host's fully-qualified DNS domain name)
Most likely it does not as the /etc/hosts contains an entry for the current machine without the domain name, as in:
127.0.0.1 localhost
127.0.1.1 nfsclient

Indeed nfs-idmapd.service is not meant to be run independently; it's a part of nfs-server.service.

I have the same experience as described in the original bug description. My system is running
on ubuntu 16.04 and I've installed `nfs-common` (client-only, I don't want `nfs-server` on the system).

# systemctl -a list-unit-files *idmap*
UNIT FILE STATE
idmapd.service masked
nfs-idmapd.service static

# systemctl status nfs-idmapd -l
● nfs-idmapd.service - NFSv4 ID-name mapping service
   Loaded: loaded (/lib/systemd/system/nfs-idmapd.service; static; vendor preset: enabled)
   Active: inactive (dead)

And starting does not work:
# systemctl start nfs-idmapd
Failed to start nfs-idmapd.service: Unit nfs-server.service not found.

Do I understand you, @pitti in #11 correctly that `nfs-server` needs to be installed?

thanks for clarifying!
andi

@backmann same happened with me on 16.04 but I was able to stop and start using
systemctl stop nfs-idmapd -l
systemctl start nfs-idmapd -l