In Jammy, rpc.statd is started always by default. It can of course be
disabled or masked as usual with systemctl.
** Changed in: nfs-utils (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubunt
** Merge proposal linked:
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/415545
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1956787
Title:
nfs v3 locking
Also, can I interest you in 1918312 for 22.04? Everyone agrees it's a
security issue. It has a well-known 2-line fix (our version is 4 lines),
which we've been using in production for over a year.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed t
That's a sensible approach, but there are loads of web pages telling
people how to set up NFS, and they all claim that on current
distributions you no longer need to enable individual services. That's
not true for Ubuntu 20.
Please do make sure it's fix in 22.04.
The original reasoning had a hole
I think the conclusion here is that on a focal server, if you expect to
server non-nfsv4 clients, you need to enable rpc-statd manually with
systemctl, and we should document it in the server guide
(https://ubuntu.com/server/docs/service-nfs).
Unless there is a trivial way to change this that for
Still digging into some history, found this patch in the package:
debian/patches/27-systemd-enable-with-systemctl-statd.patch
Description: Let sysadmins enable/disable statd services
As the admin was able to control under upstart the statd services with
NEED_STATD in default conffiles, mirror th
For the server, the nfs-server.service service should suffice:
nfs-server.service
If enabled, nfs service is started together with dependencies
such as mountd, statd, rpc.idmapd
This is a "service" file rather than a "target" (which is the
normal grouping construct) so that
I conjecture that the problem occurred when moving from init scripts to
systemd. It's pretty clear that the default in the nfs-common init
script was to start statd. I conjecture that when converting to systemd,
someone forgot to put a Wants in nfs-server. It's got an after but not a
Wants. Writing
Statd is used by both client and server. I think that note is for the
client usage.
Our servers don't necessariy do any NFS3 client mounts, so the client
start would't happen. Is it possible that at some point I mounted
something via NFS3 and that's the only reason statd was running? I can't
prove
NFS is comprised of many services (specially on nfsv3), and they differ
whenever v3 or v4 is used. The packaging tries to make the right
choices, and goes through many hoops for that.
In summary, you should have nfs-server.service enabled on the server,
and nfs-client.target (target!) on the clien
right. It's not failing. It's not running at all.
systemctl status rpc-statd
● rpc-statd.service - NFS status monitor for NFSv2/3 locking.
Loaded: loaded (/lib/systemd/system/rpc-statd.service; disabled; vendor
preset: enabled)
Active: inactive (dead)
Journalctl doesn't show that nfs-u
So if you reboot, rpc.statd will not be started? If it's failing, can
you locate that failure in the logs and show us? Also please report the
version of the package and the config files in /etc/default/* related to
nfs.
** Changed in: nfs-utils (Ubuntu)
Status: New => Incomplete
--
You re
** Summary changed:
- nfs v3 locking fails - 5.4.0-92 regression
+ nfs v3 locking fails - rpc-statd not started after minor upgrade
** Package changed: kernel-package (Ubuntu) => nfs-utils (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribe
13 matches
Mail list logo
