mounting NFS – unit rpcstatd.service not found

[ghost]

Hi everyone,

Describe the bug
On latest NixOS (with nfs-utils-2.4.1 and services.rpcbind.enable set to true), mounting NFS in a terminal gives an rpcstatd.service error.
It’s working flawlessly when automounted via fileSystems, but I’m not always on my local network with my laptop, so I need to mount my NFS folders by hand.

To Reproduce

[tcip@tlap:~]$ sudo mount -t nfs /path/to/network/folder /path/to/mount/point
Failed to start rpc-statd.service: Unit rpc-statd.service not found.
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.

[tcip@tlap:~]$ systemctl status rpcbind.service 
● rpcbind.service - RPC Bind
   Loaded: loaded (/nix/store/lhibl3d0wp3pz5gwg0vjw5diai5x8x80-rpcbind-1.2.5/etc/systemd/system/rpcbind.service; enabled; vendor preset: enabled)
  Drop-In: /nix/store/0blmb8c2axj0s7xxpkh36p5fifzjalcm-system-units/rpcbind.service.d
           └─overrides.conf
   Active: active (running) since Wed 2019-12-18 00:18:26 CET; 13min ago
     Docs: man:rpcbind(8)
 Main PID: 508 (rpcbind)
       IP: 0B in, 0B out
    Tasks: 1 (limit: 4915)
   Memory: 4.0M
      CPU: 16ms
   CGroup: /system.slice/rpcbind.service
           └─508 /nix/store/lhibl3d0wp3pz5gwg0vjw5diai5x8x80-rpcbind-1.2.5/sbin/rpcbind -w -f

Expected behavior
NFS mounting should work with remote locking, whether by script or automounted.

Additional context
See more information on NixOS’ Discourse:

• my topic – where I’ve started to seek help on this problem, and I’ve been counseled to open an issue here.
• my older (and messier) one – where you can get more on my configuration.

Metadata

[tcip@tlap:~]$ nix run nixpkgs.nix-info -c nix-info -m
 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.6, NixOS, 19.09.1690.0d9055a2ac2 (Loris)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3`
 - channels(root): `"nixos-19.09.1690.0d9055a2ac2, musnix"`
 - channels(tcip): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Thanks to all for your tremendous work and all the best,
Thomas

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[edude03]

This is still an issue for me at least, however, for future readers, this can be worked around by enabling services.nfs.server - yes, enabling the server gives you the ability to use the NFS client in this case.

[stale]

I marked this as stale due to inactivity. → More info

[koiuo]

bad stale bot, bad!

This is still an issue

[hehongbo]

I can also confirm this is still an issue.

I migrated one of my servers by deploying the same set of NixOps code to another machine and ran into this issue. And before the migration, everything works fine on every deployment attempt.

What I find related is that when I deploy the first server, I was writing the classic fileSystems statement with fsType set to nfs, and let systemd generators generate the mount unit out of fstab.

Later, I rewrote the code and declare my NFS mounts directly with systemd.mounts, along with pkgs.nfs-utils installed and services.rpcbind.enable set to true, nothing went wrong during this progress.

And the issue begin to appears when I try to deploy the same set of code onto a fresh NixOS install. So I tried to rollback my NixOps code, deploy with fileSystems statement once, and then switch to a systemd mount unit, and the problem just disappears.

Strange thing is that even if I remove the mount unit and the services.rpcbind.enable = true; statement and do a garbage collect, making sure all profiles with NFS mounts and rpcbind enabled are removed, and then add the mount unit back, everything still works.

I'm running NixOS 22.05, and updated flake inputs before this happens.
nixpkgs: github:NixOS/nixpkgs/e06bd4b64bbfda91d74f13cb5eca89485d47528f

[jhillyerd]

Adding (on 22.11):

boot.supportedFilesystems = [ "nfs" ];
services.rpcbind.enable = true;

seems to fix this without requiring nfs server to be enabled.

[elmarsto]

Adding (on 22.11):

boot.supportedFilesystems = [ "nfs" ];
services.rpcbind.enable = true;

seems to fix this without requiring nfs server to be enabled.

For me as well. 23.05

[anschott]

boot.supportedFilesystems = [ "nfs" ];
services.rpcbind.enable = true;

This is still the fix.

[edude03]

boot.supportedFilesystems = [ "nfs" ];

services.rpcbind.enable = true;

This is still the fix.

Thanks for documenting it but really if you add nfs it should enable nfs bind automatically - I guess this issue is open because it's not clear why it doesn't

[tmplt]

Repro on 23.11. boot.supportedFilesystems = [ "nfs" ]; is sufficent for a fix: it starts the required service.

What would be required for this issue to be closed? Is there a logical place to document this requirement? The manual lacks a file share chapter.

---

Tangential: not required for GNOME. If you get a Permission denied: Perhaps this host is disallowed or a privileged port is needed, ensure you allow non-root mounts on the server-side.