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 that that isn't true. I tried enabling nfs-server and that didn't help. My solution has been to enable rpc-statd explicitly. That works. The reason I reported the problem is that it had previously worked automatically, and it took me quite a while to figure out why after the upgrade NFS 3 wasn't working on the server. I might not be alone in this. It looks like it's supposed to be started by /etc/init.d/nfs-common, but I'm pretty sure that isn't started except in /etc/rcS.d/, which wouldn't normally happen. I put a statement in nfs-common to create a file in /var/log, and it didn't happen, so I don't believe nfs-common ran. I suspect statd should be started as part of nfs-server, but it doesn't seem to be happening. Unless you assume that people are just using nfs 4 and want to require manual intervention to support 3. I wouldn't expect that. Particularly since the symptoms are subtle. If you try an NFS 3 mount it works. Things don't start failing until someone tries locking. The most common case is probably firefox, thunderbird, etc, which lock their profiles. -- 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 fails - rpc-statd not started after minor upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1956787/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
