Bug#924587: please add nfs-idmapd.service to nfs-client.target
Please don't.
I'm running an NFSv4.1 environment with sec=krb5p and autofs-ldap just fine
without this.
The rpc.idmapd(8) man page says among other things:
"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."
(Aside: the libnfsidmap2 package mistakenly has the nfsidmap man page
in section 5 rather than 8, in both stretch and buster (I haven't checked sid).
Minor documentation bug.)
This applies to Debian stretch and later. I'm not starting rpc.idmapd on
client-only machines at all (the nfsidmap mechanism works for me) and
home directories are reliably being automounted. This makes me believe
that your proposed "fix" is incorrect (at least for general use; if you
need to run an old/odd kernel you may need something like this, but then
you should fix it locally in /etc/systemd/system/ and not impose it on
everyone else).
>From reading #842199 I get the impression that autofs is starting too soon,
before the LDAP server can be reached. On my systems autofs.service has an
effective
After=nslcd.service
which seems to be generated on the basis of an
# X-Start-Before: autofs
comment in /etc/init.d/nslcd (so you probably won't have this on systems
without nslcd). There are many ways to influence the order in which systemd
starts services; why pick on rpc.idmapd?
Reply to: