You are not logged in.
In researching a pure NFSV4 setup, it seems that rpcbind is not needed, yet the provided starting /usr/lib/systemd/system/nfsv4-server.service pulls some dependency that starts rpcbind. Am I missing something or is this an upstream bug? Is it an Arch packaging bug?
Thanks all.
Related old thread: https://bbs.archlinux.org/viewtopic.php?id=193629
Related bug report: https://bugs.archlinux.org/task/76453
1. Set this in /etc/nfs.conf (vers3=n under the [nfsd] section)
2. systemctl start nfsv4-server
Result:
% systemctl is-active rpcbind
active
% ps aux | grep rpc
root 1464741 0.0 0.0 4728 2980 ? Ss 08:07 0:00 /usr/sbin/rpc.idmapd
rpc 1464745 0.0 0.0 7824 3936 ? Ss 08:07 0:00 /usr/bin/rpcbind -w -f
rpcuser 1464749 0.0 0.0 4360 296 ? Ss 08:07 0:00 /usr/sbin/rpc.statd
root 1464750 0.0 0.0 4852 384 ? Ss 08:07 0:00 /usr/sbin/rpc.mountd
root 3198359 0.0 0.0 0 0 ? I< Feb01 0:00 [rpciod]
For the record, my /etc/exports:
/srv/nfs 10.9.8.0/24(ro,no_subtree_check,async,no_wdelay,fsid=0)
/srv/nfs/share1 10.9.8.0/24(rw,no_subtree_check,async,no_wdelay,no_root_squash)
/srv/nfs/share2 10.9.8.0/24(rw,no_subtree_check,async,no_wdelay,no_root_squash)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Online
Sure the socket isn't simply enabled?
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
Offline
I do not see it in the output:
% find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
cups.socket | sockets.target.wants
dbus-org.freedesktop.network1.service | system
dbus-org.freedesktop.resolve1.service | system
default.target | system
display-manager.service | system
fstrim.timer | timers.target.wants
gcr-ssh-agent.socket | sockets.target.wants
getty@tty1.service | getty.target.wants
gnome-keyring-daemon.socket | sockets.target.wants
p11-kit-server.socket | sockets.target.wants
pulseaudio.socket | sockets.target.wants
remote-fs.target | multi-user.target.wants
rngd.service | sysinit.target.wants
systemd-networkd-wait-online.service | network-online.target.wants
systemd-networkd.service | multi-user.target.wants
systemd-networkd.socket | sockets.target.wants
systemd-resolved.service | multi-user.target.wants
systemd-timesyncd.service | sysinit.target.wants
But:
% systemctl list-sockets |grep rpc
/run/rpcbind.sock rpcbind.socket rpcbind.service
0.0.0.0:111 rpcbind.socket rpcbind.service
0.0.0.0:111 rpcbind.socket rpcbind.service
[::]:111 rpcbind.socket rpcbind.service
[::]:111 rpcbind.socket rpcbind.service
And:
% systemctl list-units |grep rpc
var-lib-nfs-rpc_pipefs.mount loaded active mounted RPC Pipe File System
rpc-statd-notify.service loaded active exited Notify NFS peers of a restart
rpc-statd.service loaded active running NFS status monitor for NFSv2/3 locking.
rpcbind.service loaded active running RPC Bind
rpcbind.socket loaded active running RPCbind Server Activation Socket
rpc_pipefs.target loaded active active rpc_pipefs.target
rpcbind.target loaded active active RPC Port Mapper
Last edited by graysky (2023-02-05 14:07:50)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Online
systemctl list-dependencies nfsv4-server.service
doesn't suggest a dependency here.
Is nfs-server also active?
Edit: as aa quick mitigation you could mask socket and service or simply block port 111
Last edited by seth (2023-02-05 14:15:51)
Offline
I don't see rpc* in the output, but nfs-server is also active interestingly and for reasons I cannot explain.
% systemctl list-dependencies nfsv4-server.service
nfsv4-server.service
○ ├─auth-rpcgss-module.service
● ├─nfs-idmapd.service
● ├─nfsdcld.service
● ├─nfsv4-exportd.service
● ├─proc-fs-nfsd.mount
● ├─system.slice
● ├─network-online.target
● │ └─systemd-networkd-wait-online.service
● └─network.target
% systemctl is-active rpcbind
active
% systemctl is-active nfs-server
active
% systemctl is-active nfsv4-server
active
Circling back to my original question: is this an upstream bug or an Arch packaging bug or is it the expected behavior?
EDIT: if I build nfs-utils pulling rpcbind out of the depends array, it behaves as I expect it to behave....
Last edited by graysky (2023-02-05 15:53:17)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Online
nfs-server "Wants" rpcbind, so if it's there it'll activate it and rpcbind is a reasonable dependency for NFSv3, so it gets installed.
(I'm not sure whether you can make any use out of NFSv3 w/o it)
You can make a case that rpcbind should™ be an optional dependency, as it's only required for part of the packages functionality (NFSv3), but neither it being installed nor nfs-server activating it is a bug per se.
The bug here is that for whatever reason nfs-server is active and as long as we don't know why that is, we can't say where the bug is.
Does it get activated w/ nfsv4-server and can you stop it (and rpcbind) w/o harming the latter?
Offline
1. I can stop nfs-server while nfsv4-server is running but that breaks the exports.
2. If I build nfs-server with rpcbind as an optional dependency, I get the expected behavior (ie no rpcbind running since the package is not installed).
The FS I linked above requesting this optdepends status for rpcbind was closed stating we just package what upstream recommends. They do in fact show it as a requirement. Is the conclusion of this that the bug lies with that upstream recommendation?
Last edited by graysky (2023-02-05 16:19:38)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Online
For what it's worth, I have nfsv4-server.service enabled without nfs-server.service or rpcbind.* running.
Did you restart nfsv4-server.service after stopping/disabling nfs-server.service?
I just have these services running for NFSv4:
nfsv4-exportd.service
nfsdcld.service
I masked
nfs-idmapd.service
gssproxy.service
because I don't need them.
Offline
% grep -r nfs-server /usr/lib/systemd/system
/usr/lib/systemd/system/rpc-statd-notify.service:After=nfs-server.service
/usr/lib/systemd/system/nfs-idmapd.service:BindsTo=nfs-server.service
/usr/lib/systemd/system/nfs-mountd.service:BindsTo=nfs-server.service
% systemctl list-dependencies nfsv4-server
nfsv4-server.service
○ ├─auth-rpcgss-module.service
○ ├─nfs-idmapd.service
○ ├─nfsdcld.service
○ ├─nfsv4-exportd.service
● ├─proc-fs-nfsd.mount
● ├─system.slice
● ├─network-online.target
● └─network.target
% systemctl list-dependencies nfs-server
nfs-server.service
○ ├─auth-rpcgss-module.service
○ ├─nfs-idmapd.service
○ ├─nfs-mountd.service
○ ├─nfsdcld.service
● ├─proc-fs-nfsd.mount
○ ├─rpc-statd-notify.service
○ ├─rpc-statd.service
○ ├─rpcbind.socket
● ├─system.slice
● ├─network-online.target
● └─network.target
nvsv4-server depends on nfs-idmapd.service and that binds to nfs-server.service and that depends on rpcbind.
The upstream "bug" is in their systemd service configuration that does not allow nfsv4-server to be started w/o ultimately drawing in rpcbind.service
Also https://wiki.archlinux.org/title/NFS#En … _idmapping
So you'd enable that and edit the nvsv4-server.service to not depend on nfs-idmapd.service and that should™ prevent the invocation of nfs-server and by inference rpcbind.
Edit: as meanwhile proven by just4arch
Last edited by seth (2023-02-05 16:41:34)
Offline
Thanks guys. It is probably more simplistic to just mask rpcbind.service and rpcbind.socket vs maintaining a custom package. That seems to be giving me the desired result. Might need to update the wiki to help others. For the record, I also masked nfs-idmapd gssproxy and nfs-server and everything seems to be workin g fine.
Last edited by graysky (2023-02-06 11:02:37)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Online