We finally got the last of our recalcitrant Windows 7 users to Windows 10 thanks to MS' recent withdrawal of support from the former, so the entire enterprise now is either Ubuntu 18.04 or Windows 10.
Because Windows 10 has a NFS client, the question now is whether to ditch SAMBA in favor of NFS.
Specifically, does any reason exist to retain SAMBA now that all our Windows clients support NFS?
SMB 3.xx has a better tuned performance over "generic" TCP connectivity and has features like RDMA and multichannel support Microsoft didn't implement with "their" (actually - licensed) NFS client.
Server Message Block (SMB), the protocol used by the Samba software, might be more easily deployed with sufficient security. Network File System, abbreviated NFS, has jokingly been called "No File Security". That's the joking name, but "No File-Level Security" may be a name with some accurate implications. In other words, NFS security is based on sharing a partition, not an individual file, so file-level permissions are not enforced by the NFS protocol.
From my reading, it is possible for an NFS server to pay attention to files and reject invalid requests. However, not all NFS software will do that. The protocol tends to have the client request a block of data on a drive, and a server could fulfill that request by reading the block from the disk without necessarily require paying attention to what file that block is a part of.
Even if you found out that an NFS implementation is secure, what prevents the possibility of a change down the road resulting in a less secure implementation/deployment of NFS? If you have security concerns, then having an answer to such a question may be very worthwhile.
With SMB, people share directories rather than partitions. This can help you to feel confident that you're sharing just a directory you want to, and not other directories that are located in a different part of a drive's hierarchy.
Edit: Here comes a new challenger. A comment to this answer has made a claim that this is off-target. So, I sought some time-honored documentation that helps to back this up. And I easily found material backing up claims from my answer:
First and foremost, "Secure Networks Inc." posted a "Security Advisory" from March 7, 1997, titled "4.4BSD NFS File Handles". (That Hyperlink is from the OpenBSD website: SecList.org BugTraq Mailing List Archive from 1997: 4.4BSD NFS File Handles shows the same thing posted as part of an old mailing list, but adds a header. PacketStormSecurity: SNI BSD File Handles Advisory also shows the same document.)
This article discusses the block-based nature of how NFS served data (and is likely the source of my understanding of this particular vulnerability).
That document has been hosted by multiple organizations. Here is a different report, apparently quite unrelated to that document: parts of "Why NFS Sucks", by "Olaf Kirch" of "SUSE/Novell Inc." [email protected] say:
"NFS does not care if it is reiser, ext3 or XFS you export, a CD or a DVD. A direct consequence of this is that NFS needs a fairly generic mechanism to identify the objects residing on a file system." ... "Only the server needs to understand the internal format of a file handle." ... "Linux introduced the concept of the directory cache, aka the dcache. An entry in the dcache is called a dentry" ... "virtually all functions in the VFS layer expect a dentry as an argument instead of (or in addition to) the inode object they used to take." "This made things interesting for the NFS server, because the inode information is no longer sufficient to create something that the VFS layer is willing to operate on" ... "attackers could intercept a packet with valid credentials and massage the NFS request to do their own nefarious biddings."
As for my claim about the nickname, https://news.ycombinator.com/item?id=10967064 backs up:
in 1987, it was common knowledge among the engineers at Sun that NFS stood for "No File Security"
The first screen brings up a few different vulnerabilities, including trusting someone based on the host name that is reported by the client computer.
Google Books: quoted material from "A Practical Guide to Ubuntu Linux" notes:
Default NFS security is marginal to nonexistent (a common joke is that NFS stands for No File Security or Nightmare File System) so such access should not be allowed outside your network to machines that you do not trust.
eTutorials.org section on NFS Configuration notes:
If you mount your filesystems over the Internet, the transferred files can be interfered and even tampered with at any time (some people joke that NFS is short for "No File Security").
