CIFS/SMB vs NFS
I'm looking for thoughts on the age-old CIFS vs NFS debate. From my [somewhat limited] experience NFS is much easier to set up and just tends to work. Some of my more optimistic Windows friends think that sharing home directories between Linux and Windows would be useful. Therefore, they think I should implement CIFS home directories. From what I've found this is a fairly complicated process and the difference in security features often causes unpredictable results. I guess a lot of this is mitigated when the SMB server is on Linux. However, that won't be the case here. The share will either come from a Windows server or a 3rd party storage manager. FYI, I would want to automount home directories.
I don't want to be an uninformed zealot so I'm looking for any arguments for adopting CIFS.
Responses
Red Hat
Active Contributor
160 points
Linux and Windows use different File attributes, permissions, etc. Accessing the same folder/files via CIFS and almost anything else (NFS, Gluster FUSE, etc) can cause File locking issues, File Attribute errors, and other problems. I don't really see a short term solution for this. That being said both CIFS and NFS are moving forward, and each is adding features. If most of your clients are Windows based, go with CIFS. Otherwise, NFS may be your best bet.
Guru
6460 points
If your file servers are Windows-based and your clients are mixed, CIFS will tend to provide better performance for your Windows clients than NFS will (Microsoft does some behind-the-scenes tasks that Samba doesn't - IIRC, Intel published a performance study on the performance difference between Windows clients with Windows share-server and Windows clients with Samba share-server).
If your clients are primarily Linux, your more-portable and performant bet is likely to be NFSv4 - either on Linux or Windows 2012+. Note that, to get the more-seamless, cross-platform attribute-propagation, your RHEL clients will need to be running EL7 as the EL6 NFSv4 and IDMAP services are a touch "broken". If using a Windows 2012 NFSv4 server, you'll want everything to be speaking NFS 4.1 (there's various Google-able resources explaining the particulars of "why")..
You can actually use 3rd party products on Windows to mount NFS shares. On a quick check I see OpenText (who also make the Exceed X Windows emulator formerly known as Hummingbird Exceed) have several NFS products for Windows. There are probably others and may also be FOSS if you search.
http://connectivity.opentext.com/products/network-file-system.aspx
However, my experience has been there are far more Windows workstations than Linux so making them install a product on every workstation would likely meet with resistance.
The Samba software package in RHEL 7 includes SMB v1.*, v2.* and v3.* functionality. You don't have to "install" SMB v1.* as a separate package - just use these keywords in /etc/samba/smb.conf to specify which protocol version levels you wish to support:
client min protocol- the oldest SMB/CIFS protocol variant Samba suite will accept when acting as a client.client max protocol- the newest SMB/CIFS protocol variant Samba suite will accept when acting as a client.server min protocol- the oldest SMB/CIFS protocol variant Samba suite will accept when acting as a server.server max protocol- the newest SMB/CIFS protocol variant Samba suite will accept when acting as a server.
To see a list of possible protocol values and their explanations, see man smb.conf and search for the description of client max protocol.
For example, if you specify this, you are disabling SMB v1.* and enabling the newer versions, which should be good for any version of Windows that is currently supported by Microsoft, and protecting against the protocol vulnerability that was made infamous by the WannaCry ransomware:
server min protocol = SMB2_02
server max protocol = SMB3
client min protocol = SMB2_02
client max protocol = SMB3
If you set the (server|client) min protocol to NT1 instead, you'll also enable SMB v1 and can participate in disk sharing with Windows 2003 and older, back to Windows 95.
RHEL 7.* defaults actually go even further back: the default client min protocol value is CORE which allows Samba to act as a client with even the very oldest versions of the SMB protocol, used by the DOS-based PCLAN1.0.
The default server min protocol value is LANMAN1 which is only slightly less ancient version than CORE.
If you actually want to mount a SMB share and not just access it with smbclient or similar userspace tools, you should pay attention to the vers= mount option: see man mount.cifs.
In RHEL 7.4, the man page claims the default is still vers=1.0, which is not going to work too well with modern Windows servers that have been hardened against the original WannaCry. Instead, you'll want to specify vers=2.0 if the Windows server that's sharing the disk is Windows Vista SP1 or 2008, vers=2.1 if it's Windows 7 or 2008R2, or vers=3.0 if Windows Server 2012 or newer.