idmapd not started by systemd on nfs clients (xenial beta1)

Bug #1557015 reported by Sebastian Stark
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
nfs-utils (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

rpc.idmapd is not started on clients, but it should, especially if explicitly enabled in /etc/default/nfs-common. The corresponding systemd service appears as masked and its file (/lib/systemd/system/idmapd.service) is linked to /dev/null.

This is a regression from the previous LTS version 14.04 and prevents NFSv4 users from upgrading.

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

This is entirely by design. Per upstream, idmapd is not needed on current systems; it is superseded by the kernel upcall interface, configured via /etc/request-key.d/id_resolver.conf to use /usr/sbin/nfsidmap. Please explain why you believe this is not working.

Changed in nfs-utils (Ubuntu):
status: New → Incomplete
Revision history for this message
Sebastian Stark (sebstark) wrote :

Ok, my bad. I missed that design change. When something not worked in the beginning I just assumed that the missing idmapd was the problem. Probably got confused by the not yet updated documentation in /usr/share/doc/nfs-common/README.Debian.nfsv4.

Checked again: id mapping is indeed working for me with NFSv4. Sorry for the wrong bug report!

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

thanks for confirming. closing this report as invalid.

Changed in nfs-utils (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.