12

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?

  • 1
    What OS is your fileserver running on? If your fileserver is Windows server you should almost certainly be using SMB. – Zoredache Jan 30 at 22:15
  • 2
    In my personal experience SMB & SAMBA has faster throughput than NFS only second to HTTP (yes, even FTP is slower). NFS also has some file state issues such as being slow detecting file changes across the network compared to SAMBA. But these are my personal experience so YMMV and also why I'm not posting this as an answer. – slebetman Jan 31 at 6:51
  • 2
    In my (admittedly limited) experience managing NFS and Samba servers, permissions issues plague NFS in the end user world. In server-;land you can sync UNIX users and then everyone is happy. In the world of end users I have found there to be an never ending stream of "I can't delete that file I created" or "I can't write to that directory Bob created" support cases. Samba seems to deal more gracefully with these issues (mainly by completely ignoring permissions and rewriting everything). – Boris the Spider Jan 31 at 7:30
  • Sorry, I should have addressed our infrastructure a bit more clearly.our servers are all Ubuntu 18.04. The business side generally runs Windows 10 natively – ebsf Feb 1 at 2:37
  • I got time constrained while editing-the above should read: Sorry, I should have addressed our infrastructure a bit more clearly. Our servers are all Ubuntu 18.04. Client machines on the business side generally run Windows 10 natively. Client machines for some of the more technical staff (nwk admin, dba, finance quants) often run Ubuntu natively and Win10 virtually. – ebsf Feb 1 at 2:48
17

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.

| improve this answer | |
  • 1
    Not sure from the information the OP provided, but I wonder if the advanced SMB3.0 features matter if they are running Samba on a Linux box, or some other non-Microsoft SMB implementation. – Zoredache Jan 30 at 22:16
  • 8
    Samba supports both SMB Multichannel & SMB Direct just fine. samba.org/~metze/presentations/2018/SDC/… – BaronSamedi1958 Jan 30 at 22:31
  • 4
    @Zoredache By now, I think the Samba developers could very well understand SMB/CIFS better than Microsoft. – Andrew Henle Jan 31 at 14:27
  • @AndrewHenle sure, I guess I am just used to using the more 'enterprisy' Linux distros like Centos/Debian and it often feels like there is an extremely long lag time between new functionality in Windows, and it being available in the stable Linux release for 'production' usage, and not just in some upstream dev repo. From what I see it looks like Debian only had the full functionality in Buster(~2017)? – Zoredache Jan 31 at 17:41
  • @Zoredache: Debian did take a while to bring Samba up to date, but before that, I believe you could get Samba packages from Sernet if you wanted commercial support. (Meanwhile I built from sources for my home lab AD...) – user1686 Feb 3 at 12:41
-1

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." okir@suse.de 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").

| improve this answer | |
  • 5
    That's...not how NFS works at all. – user1686 Jan 31 at 11:56
  • 1
    (Maybe you're thinking of iSCSI, or of "pNFS Volume Layout", which is an addon feature for block-device sharing?) – user1686 Jan 31 at 11:57
  • 1
    in 1987, it was common knowledge among the engineers at Sun that NFS stood for "No File Security" That's literally 33 years ago. -1. – Andrew Henle Jan 31 at 14:38
  • 3
    SMB/CIFS didn't introduce any encryption until 3.0 - in 2012. NFS had full end-to-end encryption available in NFSv4 in 2000. So your "If you mount your filesystems over the Internet, the transferred files can be interfered and even tampered with at any time" quote applied to SMB a lot longer than it applied to NFS. – Andrew Henle Jan 31 at 14:58
  • 1
    @AndrewHenle : This has just been getting further and further from the answer's focus. May ongoing discussion commence in our chat room. – TOOGAM Jan 31 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.