Linux 6.10 Is Disabling NFS v2 Client Support By Default

[pc777]

SMB is bad for a number of reasons. In fedora, ads mode (which is patched for MIT kerberos) is not fully supported and is experimental. You are beholden to microsoft for the protocol. Really the only reasonable reason to choose smb is if you want to serve files to windows clients in native fashion.

[Lycanthropist]

NFS is plenty fast, especially if you use it over RDMA on a network that supports it.

[w466u8tw7]

If you think NFS is garbage, you're not using it correctly. The only thing that touches NFS is iSCSI

[Chugworth]

Are you sure NFSv4+ is so "bad"? It's quite used out there. SSHFS is good for quick and dirty stuff, but not so featured.

Are you so sure that NFS is still "quite used"? Security has become a very strong focus in large companies and government organizations, many of who have to deal with regular security audits. I can't believe they would still be using a protocol that could so easily give anyone access to all of your shared files.

I know that some security features have been added in NFSv4, but from what I can tell, the current state of them looks like a convoluted mess that would be a pain to set up and run. The limited documentation for those encryption features makes me think that few people have bothered with them.

Now if they ever come out with a new version of NFS that has built-in encryption with a simple authentication method, that would be great and I'd probably switch to it quickly.

[pong]

NFS is much faster than e.g. SMB when interacting with Apple systems. It's also more reliable. No need to wait for random periods of time for computers to show up in the local network view. SSHFS also requires tons of CPU power, especially on older systems. Gigabit half-duplex ethernet already saturates a Pentium 4 CPU completely.

If that's mostly for the crypto, you may be able to tune the cipher options based on the particular peers so that it uses something much faster than the default.
I've done that for ssh sometimes wrt. older systems that had that problem.

[pong]

Are you so sure that NFS is still "quite used"? Security has become a very strong focus in large companies and government organizations, many of who have to deal with regular security audits. I can't believe they would still be using a protocol that could so easily give anyone access to all of your shared files.

I know that some security features have been added in NFSv4, but from what I can tell, the current state of them looks like a convoluted mess that would be a pain to set up and run. The limited documentation for those encryption features makes me think that few people have bothered with them.

Now if they ever come out with a new version of NFS that has built-in encryption with a simple authentication method, that would be great and I'd probably switch to it quickly.

Well there is such a thing as layering and one tool for one job.
So you could run NFS over your favorite secure tunnel e.g. VPN, IPSEC, ... which could solve some aspects of encryption and authentication.

The problem with "build in encryption" often is that everyone tries to reinvent the wheel (often disasterously poorly) and then one ends up with 100 various incompatible bad things one is "stuck with" rather than a handful of really common / robust things one can relatively more homogeneously trust / sysadmin / deploy without a lot of cognitive / administrative overhead to deal with everyone's favorite port, protocol, config options, ....

[Chugworth]

Well there is such a thing as layering and one tool for one job.
So you could run NFS over your favorite secure tunnel e.g. VPN, IPSEC, ... which could solve some aspects of encryption and authentication.

The problem with "build in encryption" often is that everyone tries to reinvent the wheel (often disasterously poorly) and then one ends up with 100 various incompatible bad things one is "stuck with" rather than a handful of really common / robust things one can relatively more homogeneously trust / sysadmin / deploy without a lot of cognitive / administrative overhead to deal with everyone's favorite port, protocol, config options, ....

It can be done. Take WireGuard for example. A brand new protocol that's small, elegant and secure by design. It doesn't send your data raw and unencrypted by default, and expect you to piece together a bunch of services in order to make it secure.

VPN has it's place though, and that's for making secure connections over the Internet. If I just wanted to securely share files within a company network then wrapping every file share within its own VPN connection would get very ugly.