Apart from Kerberos, you can use it in a safe way in all-squash mode, where access from certain IPs are always interpreted as a certain UID. So if you're e.g. distributing built code to your network, doing all-squash to a user with read-only permissions would work.

This requires a trustworthy routing config (or a way to write files using something other than NFS) but allows untrusted clients as long as someone is keeping them out of trusted subnets.

Note that unlike all-squash, root-squash is not a meaningful security measure, since an untrusted root user can just become whatever UID they want. It's simply a (useful) protection against mistakes as root.

I've actually implemented NFS servers professionally (for my sins) and used various competitor implementations. It's possible with the mechanisms others have mentioned, but ultimately each vendor has its own specific ways to circumvent the "Kerberos is annoying and often not well configured at the client" issue[0]/allow various 'hacks' to be deployed, so if you're interested in a specific vendor's product (e.g. ONTAP) the best option is to look through their online manual for the specific CLI/Web GUI features, usually around root squashing and the like.

[0] I actually really like it, but the reality and customer feedback is what it is...

In what way are implementations not inter-operable? The SunOS and Linux implementations, at least, coexist happily (modulo ACLs). Do others fail to implement the standard?

Is Kerberos even an option in an environment with Mac OS & mobile phone clients, as well as Windows?

It is, but (IMHO):

1. There aren't many NAS devices that gracefully interact with both Active Directory and Kerberos (if you care about that, for both SMB and NFS access to the same storage). The best that I know that is still commercially available is ONTAP (I was not employed by them, but a competitor). I don't know much about its internals, but was impressed with the features, team, my own play with it, etc. It's also the most expensive. If interoperability with AD is not an issue, then disregard.

2. Mac OS X support for NFS v4 and its variants is abysmal. To the point that I could craft packets that would cause a reboot on the latest OS (which to me yells probable 0-day... but hopefully fixed since then and security analysis is not my expertise). Their SMB client is really good though, second to Windows in terms of keeping up with features, using them correctly, etc.

3. What's the use case for the mobile devices? The NFS/SMB clients I've seen for mobile are clunky as hell, but it was also never my focus.

While still only my opinion, this is true up to early 2017. I've since moved to another industry and don't actively research it anymore.

I've used krb5 and nis in an osx environment with NFS as file store. My basic opinion is that osx is not about unix legacy and they move as desired. Running on osx is agsinst a moving target.

Unsuitable for production.

On my home Mac, /Users lives on kerberized NFS. It was painful to configure but it does work.

I have used kerberos on Windows too without issue, though not NFS so not sure how good its NFS client is. (It does have one.)

Mobile phones using NFS with kerberos? I doubt it.

You can set up Kerberos authentication, but I've never actually seen this done in the wild.

Most setups trust based on subnet.

It's a lot more common than pNFS, which I've never seen. You really don't want anything else unless you have tightly-coupled, well-managed clients.

If you can trust the existing machines, but are worried about new machines sniffing and spoofing, you can set up IPsec between the NFS clients and the NFS server.

With kerberos authentication you can also require traffic encryption.

> krb5p Use Kerberos for authentication, and encrypt all traffic between the client and server. [0] https://wiki.debian.org/NFS/Kerberos

I wish there was a middle ground where you could issue a ticket to the server and not have to issue one per user but still have the traffic encrypted between NFS client and NFS mount.

Hm, would NFS over WireGuard do what you want? Or over stunnel, maybe?

Since WireGuard securely attaches an IP address to a public key, NFS over WireGuard may actually be a viable solution.

Thanks for the suggestion I'll look into it!

Perhaps you'd like to read up on NFS basics.

The short answer is, you can use it with either loose or tight authentication. The "LAN" bit of your question is largely irrelevant.