Limitations of PC/NFS (Managing NFS and NIS, 2nd Edition)

10.2. Limitations of PC/NFS

The NFS protocol is the lingua franca of file-sharing protocols in that it is implemented on the widest variety of operating system environments, both client and server. These environments include Unix (nearly all of them), Windows, NT, MacOS, MVS, OS/400, OS/2, VMS, many real-time operating systems, and systems designed for network-attached storage, such as the ONTAP system for Network Appliance's hardware. One reason why NFS has been so successful is that it is very simple. This simplicity has a price; NFS does not take the approach of supporting every arcane, operating-specific file semantic for all the environments it supports. Using NFS on non-Unix platforms, especially as a client, can limit you. This is very noticeable with PC/NFS. For example, the Windows and NT worlds have notions of enforced locking, which NFS, even via the NFS Lock Manager, does not provide. While PC/NFS implementations do their best to emulate this semantic and others, you will find that some applications work in unexpected ways over NFS.

These limitations apply to NFS Versions 2 and 3. NFS Version 4 goes a long way toward supporting Windows and NT file semantics. At the time of this writing, there were no known generally available NFS Version 4 implementations.

10.2.1. NFS versus SMB (CIFS)

SMB stands for Server Message Block and is the file access protocol that is native to Windows and NT. In 1996, Microsoft, the owner of the SMB protocol, renamed SMB to CIFS: the Common Internet File System. However, at the time of this writing, CIFS was not as common as NFS when it came to came to the variety of client implementations. CIFS is, however, growing in the number of server implementations. When you consider the plethora of low-end, network-attached storage boxes aimed at consumers and small office environments, that often support CIFS but not NFS, it is arguable that CIFS has surpassed NFS in the number of unique server implementations. The installed base of Windows and NT desktop computers as compared to non-Windows, non-NT desktops is a big reason for this trend.

Unix is becoming a popular platform for CIFS servers. This is likely due to the popularity of the open source package called Samba, which is a CIFS server for Unix platforms. Samba is developed and maintained by a world-wide community of programmers dedicated to producing a server as compatible with Microsoft's clients as possible. This is no mean task; at the time of this writing, the shared opinion of many in the CIFS server industry was that published CIFS specifications were inadequate to build a compatible server. The Samba developers, and no doubt other non-Microsoft implementors, have often resorted to using packet sniffers between existing Windows and NT clients and servers to deduce the protocol formats and semantics.

The emergence of Samba has led to a massive shift from deploying PC/NFS to deploying Samba instead. This is for at least three reasons:

Samba is free of charge under Free Software Foundation's GNU Public License.

It is easier for system administrators to install and maintain Samba on a few server hosts than to install and maintain PC/NFS on many client hosts.

It is perceived that SMB has better security than NFS. This is false. Nor is it quite true to say that NFS has better security. You can have Kerberos V5 (see Section 12.5.5.1, "Kerberos V5") security for your collection of PC/SMB clients if all your SMB servers run Windows 2000.[15] You can have Kerberos V5 security for certain PC/NFS clients if all your servers support NFS secured with Kerberos V5.[16]
[15]At the time this book was written, only SMB servers on Windows 2000 supported Kerberos V5 security, partly because the Windows 2000 Kerberos V5 is incompatible with Kerberos V5 specification in RFC 1510. See the article, "Microsoft "embraces and extends" Kerberos V5," by Theodore Ts'o (USENIX ;login, November, 1997).

[16]See Section 12.5.4.10, "How secure is RPC/DH?" for the set of known NFS servers and PC/NFS clients that support Kerberos V5.

However, when comparing a situation where you cannot run Windows on all your SMB servers with a situation where you cannot run NFS servers that support Kerberos V5 or NFS/dh, (see Section 12.5.4, "AUTH_DH: Diffie-Hellman authentication"), then the SMB environment is more secure.

10.2.2. Why PC/NFS?

With the ubiquity of CIFS servers on Unix platforms, it begs the question, why run NFS on a Windows or NT client? This question was asked of the comp.protocols.smb and comp.protocols.nfs Usenet newsgroups in the summer of 2000. The responses can be summarized as follows:

Speed

Some respondents claimed that NFS was faster. An article by Jeff Ballard for Network Computing magazine's web site ("Increasing File Access Through SMB," March 6, 2000, www.nwc.com) compared three Unix-based SMB servers. An interesting quotation from the article is:

If it's speed you want, NFS is probably a better solution [than SMB] for you.

Some direct research was done to investigate such claims. A 256 MB file was created in the /tmp directory of a Solaris 8 file server. The server was an Ultra 10, with a 440 Mhz Ultra Sparc II processor and 512 MB of primary memory. A Windows 98 client (a Sony Vaio Z505HS, with a 500 Mhz Pentium III processor and 128 MB of primary memory) was used to copy (via Windows Explorer) the file between the file server and client. Using Samba as the SMB server, and native SMB client in the client, copying the file from the server to the client's My Documents folder took about one minute. However copying the file from the My Documents folder to the SMB server took about ten minutes. When using a free evaluation copy of an NFS client on the client, and the native NFS server on the Solaris 8 system, the respective file transfer times were about 45 seconds each. The quoted times are qualified with "about," because Windows Explorer did not display file transfer times, leaving the tester timing the results with the second hand of a timepiece.

The informal results were obtained without any tuning of the Solaris NFS server or the Samba server. It is quite possible that tuning the Samba server would have improved performance. Also, single stream file transfer speed is only one part of performance. About the only conclusion you should make is that you need to consider performance when making the decision to use NFS or SMB on Windows or NT clients.

Administrative complexity

Administering an SMB server is much different than administering an NFS server. Even if you are primarily a Unix shop with some Windows or NT clients, running an SMB server is still going to require at least as much expertise as running an NFS server.

One respondent said if you have few (ten or less) potential SMB clients, then you should strongly consider the trade-off of purchasing and installing commercial PC/NFS products on Windows and NT systems, versus devoting administration resources to SMB.

It required most of a day to install and configure the precompiled Samba binaries on the Solaris 8 server, plus lots of fiddling on the Windows 98 client, before the Network Neighborhood folder would recognize the Solaris 8 server. One unexpected result was that the passwords for SMB users apparently have to be managed separately from the corresponding Unix passwords, due to absence of an NTLM server on the network. This is because the Windows 98 client in the testbed was apparently sending encrypted passwords. Since the password database in NIS or files encrypts the passwords with a different scheme than Windows 98, Samba provides the option to maintain a separate database.

Software compatibility

One respondent claimed that there are Windows- or NT-based applications that work only over NFS. Rational's Clearcase, a software configuration management (source code control) system, was found to be an example.

There is one more consideration: reliability. The SMB protocol is based on TCP/IP and is very stateful, like the NFS lock manager. State recovery is very simplistic; when the TCP connection between an SMB client and server is lost, the SMB server removes all state that belongs to the SMB client. There is no mechanism to allow a client to reestablish state. In contrast to the NFS environment, the filing protocol has no state to recover. The NFS environment's locking protocol is stateful, but there is a state recovery mechanism: clients are given a grace period to re-establish state. The consequence of the SMB approach is that a client has a higher opportunity to lose its locks and other valuable state after a server restart than with the NFS environment. Andy Watson and Paul Benn, in a white paper from Network Appliance ("Multiprotocol Data Access: NFS, CIFS, and HTTP," TR3014, Revision 3, May 1999, www.netapp.com), wrote:

If a CIFS client attempts file access on an established connection while the server is unavailable (down or not yet finished rebooting), this is effectively the equivalent of a failed disk from the perspective of the application software. In many cases, the application will report an error and allow the user to retry, but some applications will simply hang or exit.

At the time this book was written, this statement was true for both Windows ME and Windows 2000. However, there are rumors that future versions of Windows will address this recovery issue.