Hello all,
Steve Langasek pointed out in [1] that idmapd is also necessary on the client
side. It isn't for my very simple NFSv4 test, but then again I don't know that
much about the various other modes of operation.
This patch starts nfs-idmapd.service on clients too.
Thanks,
Martin
[1] https://launchpad.net/bugs/1428961
idmapd is needed on clients too, so start it from nfs-client.target and stop
binding to it in nfs-server.service.
https://launchpad.net/bugs/1428961
---
systemd/nfs-client.target | 4 ++--
systemd/nfs-idmapd.service | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target
index 9b792a3..b12d830 100644
--- a/systemd/nfs-client.target
+++ b/systemd/nfs-client.target
@@ -5,8 +5,8 @@ Wants=remote-fs-pre.target
# Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to
# start that on demand if needed.
-Wants=nfs-blkmap.service rpc-statd-notify.service
-After=nfs-blkmap.service
+Wants=nfs-blkmap.service rpc-statd-notify.service nfs-idmapd.service
+After=nfs-blkmap.service nfs-idmapd.service
# GSS services dependencies and ordering
Wants=auth-rpcgss-module.service
diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service
index df3dd9d..90d3731 100644
--- a/systemd/nfs-idmapd.service
+++ b/systemd/nfs-idmapd.service
@@ -4,8 +4,6 @@ DefaultDependencies=no
Requires=var-lib-nfs-rpc_pipefs.mount
After=var-lib-nfs-rpc_pipefs.mount local-fs.target
-BindsTo=nfs-server.service
-
Wants=nfs-config.service
After=nfs-config.service
--
2.1.4
Hello,
On 03/06/2015 06:15 AM, Martin Pitt wrote:
> Hello all,
>
> Steve Langasek pointed out in [1] that idmapd is also necessary on the client
> side. It isn't for my very simple NFSv4 test, but then again I don't know that
> much about the various other modes of operation.
>
> This patch starts nfs-idmapd.service on clients too.
This is distro specific... Other distros use the
key ring based nfsidmap(5) command to do the id mapping.
Make note, with new kernels the default upcall is to the
nfsdimap command, if that fails then the rpc.idmapd daemon
is tried. Meaning there are two upcalls for every id map
when rpc.idmapd is used. This was the reason for the switch.
steved.
On Fri, Mar 06, 2015 at 11:49:33AM -0500, Steve Dickson wrote:
> On 03/06/2015 06:15 AM, Martin Pitt wrote:
> > Hello all,
> > Steve Langasek pointed out in [1] that idmapd is also necessary on the client
> > side. It isn't for my very simple NFSv4 test, but then again I don't know that
> > much about the various other modes of operation.
> > This patch starts nfs-idmapd.service on clients too.
> This is distro specific... Other distros use the
> key ring based nfsidmap(5) command to do the id mapping.
> Make note, with new kernels the default upcall is to the
> nfsdimap command, if that fails then the rpc.idmapd daemon
> is tried. Meaning there are two upcalls for every id map
> when rpc.idmapd is used. This was the reason for the switch.
Ah, thanks for the feedback. We do have nfsidmapd enabled, I had overlooked
that rpc.idmapd was no longer being used on the client. We'll stick with
just using nfsidmap then.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
[email protected] [email protected]