Hence why even on UNIX people moved on from NFS, but on Linux it keeps being the remote filesystem many reach for.

NFS is more annoying on Linux than just using Samba though, at least for the NAS use case. With Samba on my server I can just browse to it in KDE's file manager Dolphin, and samba configuration is a relatively straight forward ini style file on the server. A pair of ports also need to be opened in the host firewall.

Contrast that with NFS, which last I looked needed several config files, matching account IDs between hosts, mounting as root, and would hang processes if connection was lost. At least I hear rpcbind is gone these days.

I don't think anyone sane uses NFS on Linux either these days. And it is rather funny that the protocol Microsoft invented is what stuck and became practical between Linux hosts.

NetApp has NFS support and is widely used.

First thing I have heard about NetApp. Seems to be some enterprise focused company, with more than one product. Not sure which product of theirs you refer to.

Synology, TrueNAS and Proxmox probably also have NFS support I would assume, and they definitely have Samba. Those are more relevant to me personally.

I just run a normal headless Linux distro on my NAS computer, I don't see the point of a specialised NAS distro. It too could have NFS if I wanted it, but it currently has Samba, because it is easier and works better.

So in conclusion, I'm not sure what your point is? Doesn't NetApp support anything except NFS?

> it is easier and works better

For me NFS is easy and works better, edit two files, enable NFS and update firewall. I had NFS running before SMB, and if I am at hobby level I prefer http if it is good enough. There are technical reasons to use SMB, HTTP, NFS or Ceph. The easy to use options is just a function of how much you know, what you have run into and what you NEED to do.

For me it was the path of least resistance, I do use WebDAV more now since Copyparty supports it out of the box but I would be open to suggestions

Samba/SMB, Network protocols like WebDAV, S3, Docker, OneDrive,....

No, any remote system would have the same problem if one expected to use it as if it were local.

Not quite. For persistence latency, yes.

For read-only access there could be way better caching, especially for common use cases like listing the contents of a filesystem directory. But stuff like this was excluded on purpose.

NFS is really stupid.

NFS made the assumption that a distributed system with over 100 times the latency of a local system could be treated like a local system in every single way.

I am not sure why this means why "NFS is really stupid" if the user assumes that a distributed file system can be treated just like a local system. That is provides the same interface is what makes NFS extremely useful.

And also, this is what makes NFS useless.

Latency is at least two orders of magnitude higher. That is the (relevant) difference here. And treating it like a loc system with all the incidental non-optimizations made the NAS use-case take 40 hours for colored "ls" output.

I find it extremely useful and it works well for many use cases. This already implies that "it is useless" is pure nonsense. If it does not work for your usecase, just don't use it.

The basic argument was "NFS is stupid". The basis for this claim is its data model being ill-suited to network latency. This is different from "useless".

It's wasn't "NFS", it was always the users that made that mistake. NFS can be used in a proper and productive manner, but it requires adjustments.

Which all boil down to "replace NFS with something that has a better data model."

Any remote data system would have the same problems. Looping over a list and synchronously fetching files one by one is equally foolish for S3 too.

That is the point.