NFS Advertising and Authentication

[melonion]

First of all, is there a way to advertise an NFS share in the local network?
I can discover all SMB shares in the network via nmblookup -S '*', is there an equivalent for NFS?
See also https://www.reddit.com/r/samba/comments/102twvr/discovery_and_mounting_via_tui/

Then for authentication, how can I easily setup authentication either username-pass or with certs for NFS, ideally with the ability to restrict access to subfolders of the share?
This old thread mentions Kerberos for NFS, but without any helpful info: https://www.truenas.com/community/threads/kerbos-nfs-setup.35477/
I also found https://www.truenas.com/docs/core/coretutorials/directoryservices/kerberos/, but I am struggling to understand anything in there.

 

[Patrick M. Hausen]

NFS up until version 3 does not have such a concept as authentication. NFS mounts are not per user but from system to system centrally managed by an administrator. It is assumed that numerical user and group IDs are identical across all systems (by NIS or e.g. LDAP) or also manually mapped (hence the "maproot" and "mapuser" parameters) so all systems have the correct view of who is who.

NFSv4 has introduced more granular controls and Kerberos into the game but I never made the effort to look into that. SMB is pervasive for desktop and other "client" systems and for server to server mounts like e.g. VMware NFS v3 is still good enough.

Same for discovery - this is really a multi user server to multi user server protocol and it shows. You could surely created an ahavi configuration that advertises NFS service on the local network but that is not part of the TrueNAS UI.

HTH,
Patrick

 

[anodos]

Same for discovery - this is really a multi user server to multi user server protocol and it shows. You could surely created an ahavi configuration that advertises NFS service on the local network but that is not part of the TrueNAS UI.

The problem with advertising the NFS SRV records over mDNS is that you actually need a client / application that knows to look for them. If there's an actual use-case for it (for instance MacOS has a quasi-documented way to discover NFS servers via txt record in NFS srv record over mDNS) then we can maybe add it to our avahi config.

Kerberos doesn't really impact discovery of NFS servers except in the sense that it forces the admin to be aware of what's on the network and have functioning DNS.

 

[melonion]

So in essence, the NFS Server trusts the client.
Now I start to understand.

So if I expose my TrueNAS to the internet, I should restrict NFS access to the local network, for example 172.16.0.0/16:
> Space-delimited list of allowed networks in network/mask CIDR notation. Example: 1.2.3.0/24. Leave empty to allow all.

 

[anodos]

So in essence, the NFS Server trusts the client.

It depends on how you have configured NFS security on the server. In non-kerberos case (sec=sys), typically client operates with ids that it asks for. Setting up sec=krb5 in an environment is probably a pretty heavy lift for most admins / users. It requires knowledge of kerberos, DNS, NFS protocol, (and typically LDAP as well).

TL;DR, if you're at all concerned about security, don't expose NFS servers to non-trusted clients / networks (unless you have sec=krb5).