Win10 NFS Client a SAMBA Killer?

Question

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?

Solution

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.

Comments

[Zoredache]

What OS is your fileserver running on? If your fileserver is Windows server you should almost certainly be using SMB.

[slebetman]

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.

[Boris the Spider]

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).

[ebsf]

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]

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.

[c4f4t0r]

@slebetman nfs hasn't any caching issue, you only need to use noac in the client side :)

[Zoredache]

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.

[BaronSamedi1958]

Samba supports both SMB Multichannel & SMB Direct just fine. samba.org/~metze/presentations/2018/SDC/…

[user1686]

That's...not how NFS works at all.

[user1686]

(Maybe you're thinking of iSCSI, or of "pNFS Volume Layout", which is an addon feature for block-device sharing?)

[Sumeet Kashyap]

This is somewhat mangled, but it's true that NFS authentication is extremely poor and you can just impersonate UIDs.

[Andrew Henle]

@pjc50 Only if the NFS server is using AUTH_SYS authentication. And anyone who already has root/admin privileges and the knowledge to get inside their system and spoof UIDs/GIDs over NFS likely has the ability to do the same to SMB, too. And hack your entire system anyway.

[Andrew Henle]

@Zoredache By now, I think the Samba developers could very well understand SMB/CIFS better than Microsoft.

[TOOGAM]

@AndrewHenle : root may be unnecessary. "hackers" ... "who attacked Unix systems in (say) 1995 had a copy of NFS shell." "a user can then mount any exported filesystems, performing arbitrary filesystem operations as any non-root user, assuming they are on a host in the server's export list. Such access will commonly result in the user obtaining root privileges." "userland code was sufficient for authentication. And the mountd returned the root handle of the file system. When you presented that handle to nfsd it would happily serve you even when you are no longer in the exports table."

[Andrew Henle]

@TOOGAM who attacked Unix systems in (say) 1995 So hacks against Windows 95 are valid arguments against Windows implementations today?

[Andrew Henle]

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.

[TOOGAM]

@AndrewHenle Yes. If there is a protocol that is known for having a ton of vulnerabilities, I would want to know that the protocol has removed such design flaws. At which point, it is essentially a new protocol. Otherwise, you may be relying on various workarounds that people try to tack on to secure things better, but who knows when an update or a different implementation will fail to implement those same workarounds, or when another issue arises because of the initially insecure design. Besides, I essentially wasn't promoting absolute final conclusions, just considerations to keep in mind.

[TOOGAM]

(The reason why Sun was so significant is that Sun invented NFS.)

[Andrew Henle]

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.

[TOOGAM]

@AndrewHenle : This has just been getting further and further from the answer's focus. May ongoing discussion commence in our chat room.

[Zoredache]

@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)?

[user1686]

@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...)