Arch Linux

dawnofman

Member

Registered: 2019-07-26

Posts: 140

is nfs-idmapd service required when using NFSv4 manual mapping ?

I already and succesfully installed/configured NFS on my arch-linux server (serving content from BTRFS directories) and my workstation and the setup is working flawlessly.

I am using NFS version 4.2 for no particular reason: I wanted version 4 and so I enabled the newer one.

I have matching user and group IDs on the server and the workstation so, in principle, I do not have any need for mapping services. As you can later see in the provided configuration details I have some shares (whatever1 through whatever3) requiring this, and, another anonymous share (setup) that should map remote UID/GIDs to some specific UID/GID on the server: the use case for this share is installing new systems since while installing a new one I won't have any custom user and group already in place:

Following is an excerpt from /etc/fstab on the workstation:

…
server.domain.com:/whatever1 /data/whatever1 nfs4 defaults,vers=4.2 0 0
server.domain.com:/whatever2 /data/whatever2 nfs4 defaults,vers=4.2 0 0
server.domain.com:/whatever3 /data/whatever3 nfs4 defaults,vers=4.2 0 0
server.domain.com:/setup     /data/setup     nfs4 defaults,vers=4.2 0 0
…

Following is an excerpt from /etc/fstab on the server:

…
/data/whatever1 /nfs/whatever1 none bind 0 0
/data/whatever2 /nfs/whatever2 none bind 0 0
/data/whatever3 /nfs/whatever3 none bind 0 0
/data/setup     /nfs/setup     none bind 0 0
…

Following is an excerpt from /etc/exports on the server:

/nfs *(rw,no_subtree_check,fsid=0)

/nfs/whatever1 workstation.domain.com(ro,no_subtree_check,root_squash,mountpoint) ### requiring same UID/GIDs on server/workstations
/nfs/whatever2 workstation.domain.com(ro,no_subtree_check,root_squash,mountpoint) ### requiring same UID/GIDs on server/workstations
/nfs/whatever3 workstation.domain.com(rw,no_subtree_check,root_squash,mountpoint) ### requiring same UID/GIDs on server/workstations
/nfs/setup *(ro,no_subtree_check,all_squash,anonuid=1009,anongid=1509,mountpoint) ### allowing anonymous access mapped to server's UID=1009/GID=1509

Following is full /etc/exports on the server:

[general]

   pipefs-directory='/var/lib/nfs/rpc_pipefs';

[nfsd]

   vers4.2='yes'; ### minor‐version wanted
   vers4.1='no';
   vers4.0='no';
   vers4='yes'; ### major‐version required by the one wanted
   vers3='no';

   rdma='y';
   rdma-port='20049';

[exports]

   rootdir='/nfs';

systemctl | grep nfs; ### on the server:

nfs-whatever1.mount          loaded active mounted /nfs/whatever1
nfs-whatever2.mount          loaded active mounted /nfs/whatever2
nfs-whatever3.mount          loaded active mounted /nfs/whatever3
nfs-setup.mount              loaded active mounted /nfs/setup
…
proc-fs-nfsd.mount           loaded active mounted NFSD configuration filesystem
var-lib-nfs-rpc_pipefs.mount loaded active mounted RPC Pipe File System
nfs-idmapd.service           loaded active running NFSv4 ID-name mapping service
nfs-mountd.service           loaded active running NFS Mount Daemon
nfs-server.service           loaded active exited  NFS server and services
nfsdcld.service              loaded active running NFSv4 Client Tracking Daemon

Questions/Issues:

When I boot the server the shares do not come up because the nfs-server is not resolving computer names, this is obviously due to my BIND server (on the same machine) coming up later on the boot sequence; but if I manually do systemctl restart nfs-server (which I am actually doing) everything is fine, so my first impulse was to add a custom nfs-server.service unit under /etc/systemd/system to state that this service requires and/or should come after named; but searching this forum I hit a post for something similar on the client-side stating that there's a bg option meaning background mount that can be used in /etc/fstab that actually forks the mount while stating successful mount (exit code 0) thus allowing more time for everything else to come up.

Do I need the nfs-idmapd service up-and-running ? ... I guess not at all since I am manually setting the UID/GID translation on /etc/exports.

Regarding the nfsdcld service: dunno what it does/required for ... needing to research it: the man page for nfsdcld talks about tracking clients and network partitions and I don't have a clue what are those to begin with.

I also learned that if I want to serve content from ZFS directories I need to add more specific things to this config, but that should wait a bit, till I feel at ease and fully-understand the inner-workings of this one.

And obviously, since you're seeing my full config any tips/fixes/don't-do-this are welcome

koffeinfriedhof

Member

Registered: 2017-11-30

Posts: 91

Re: is nfs-idmapd service required when using NFSv4 manual mapping ?

Do I need the nfs-idmapd service up-and-running ?

No. As you are still relying on matching user ids (and not names) there is no need for it. If you want to map usernames instead of ids, you should set it up.

The nfsdcld can be safey ignored until you have lock issues or similar on server reboots or network connection losts (nfsv4 only).

dawnofman

Member

Registered: 2019-07-26

Posts: 140

Re: is nfs-idmapd service required when using NFSv4 manual mapping ?

Do I need the nfs-idmapd service up-and-running ?

No. As you are still relying on matching user ids (and not names) there is no need for it. If you want to map usernames instead of ids, you should set it up.

The nfsdcld can be safey ignored until you have lock issues or similar on server reboots or network connection losts (nfsv4 only).

I think enabling nfs-server does not automatically enable nfs-idmapd and nfsdcld which I have running. I think that while I was setting things up and experimenting with various different setups I manually enabled one or both. Yesterday I disabled nfs-idmapd only and on reboot it keeps coming running as "static"; maybe it is related to nfsdcld also. I will try to disable nfsdcld and see what happens.