Years ago I wrote about my then desires for a better version of NFS here and here. Since then I've revised my opinions somewhat and today (prompted by a comment here) I want to talk about it again.

We have two use cases, which for convenience I will call 'NFS v3' and 'Samba'. The NFS v3 use case is traditional Unix filesystem activity between trusted machines, where it is an important feature that the servers trust the client machines to properly identify users (because insisting otherwise means you lose a number of important capabilities). The Samba use case is giving an individual user access to their files without trusting their machine to properly identify users, because their machine is not under our control and security.

Then, what I would like in a future version of NFS is:

• strong 'machine' authentication involving shared secrets via public key cryptography or the like. IP addresses are no longer good enough. We are already kludging our own solution but I would like a better one that is integrated into the protocol.

• per-machine (and per-filesystem) flexible UID and GID mapping. I think that in theory you might be able to do this today with NFS v4 if you had suitable software on the server side (but current Linux software doesn't do it).

  (This would let you handle the 'Samba' case; just give user machines an extremely restricted mapping.)

• optional encryption for the transport stream. It needs to be optional so that it doesn't slow down the 'trusted machines on a trusted network' case.

I used to think that I wanted sub-filesystems to be automatically mounted and accessible. It's okay if this happens but I'm no longer convinced that it's as useful as I thought it would be; in many real cases you do not want how filesystems are associated together to be clearly visible to users because such associations can change.

I don't think you can do machine authentication in NFS v4 as it stands (at least without going fully into strong authentication for the users) but you might be able to get everything else by allowing some machines to 'authenticate' with NFS style 'I trust the client' authentication and then insisting that everyone else support Kerberos authentication.

(Or maybe NFS v4 can actually do machine authentication via Kerberos and then trust the client's UID/GID/name information. I haven't looked at NFS v4 too much for various reasons, including an inaccurate perception that it actively required Kerberos and couldn't be used in the traditional NFS way.)

However I'm not sure that the 'Samba' usage case is very important or interesting for NFS specifically. We do have some people who run their own Unix machines and would like to mount some NFS filesystems but I rather expect that almost all user machines will be Windows or Macs and are not going to have NFS clients (v4 or otherwise). On the other hand, there is one potentially common case of user-run Unix machines and that is cloud computing instances; it would be nice to provide researchers using them with a relatively frictionless way of getting good access to our filesystems.

(Given the bandwidth charges that cloud computing provides like to levy, the researchers might not want to use it. But at least we'd be able to give them an option.)