Sun used version 1 only for in-house experimental purposes. When the development team added substantial changes to NFS version 1 and released it outside of Sun, they decided to release the new version as v2, so that version interoperation and RPC version fallback could be tested.[2]

NFSv2 originally operated only over UDP. Its designers meant to keep the server side stateless, with locking (for example) implemented outside of the core protocol.[1] The decision to make the file system stateless was a key decision, since it makes recovery from server failures trivial: all network clients freeze up when a server becomes unavailable, but once the server is again operational all the state to retry each transaction is contained in each RPC, which is retried by the client stub(s). This design decision allows UNIX applications, which usually cannot tolerate file server crashes, to ignore the problem.

support for 64-bit file sizes and offsets, to handle files larger than 2 gigabytes (GB);

support for asynchronous writes on the server, to improve write performance;

additional file attributes in many replies, to avoid the need to re-fetch them;

a READDIRPLUS operation, to get file handles and attributes along with file names when scanning a directory;

assorted other improvements.

At the time of introduction of Version 3, vendor support for TCP as a transport-layer protocol began increasing. While several vendors had already added support for NFS Version 2 with TCP as a transport, Sun Microsystems added support for TCP as a transport for NFS at the same time it added support for Version 3. Using TCP as a transport made using NFS over a WAN more feasible.

NFS version 4.1 (RFC 5661, January 2010) aims to provide protocol support to take advantage of clustered server deployments including the ability to provide scalable parallel access to files distributed among multiple servers (pNFS extension). NFS version 4.2 is now available

Not everyone was happy with the new protocol. In 2010, OpenBSD's Theo de Raadt wrote: "NFSv4 is not on our roadmap. It is a ridiculous bloated protocol which they keep adding crap to."[6]

WebNFS, an extension to Version 2 and Version 3, allows NFS to integrate more easily into Web-browsers and to enable operation through firewalls. In 2007, Sun Microsystems open-sourced their client-side WebNFS implementation.[7]

Various side-band protocols have become associated with NFS, including:

SMB and NetWare Core Protocol (NCP) are more common than NFS on systems running Microsoft Windows, AFP is more common than NFS on Macintosh systems, and QFileSvr.400 was once more common on IBM i systems. Haiku recently added NFSv4 support as part of a Google Summer of Code project.

Assuming a Unix-style scenario in which one machine (the client) requires access to data stored on another machine (the NFS server):

The server implements NFS daemon processes (running by default as nfsd) in order to make its data generically available to clients.

The server administrator determines what to make available, exporting the names and parameters of directories (typically using the /etc/exports configuration file and the exportfs command).

The server security-administration ensures that it can recognize and approve validated clients.

The server network configuration ensures that appropriate clients can negotiate with it through any firewall system.

The client machine requests access to exported data, typically by issuing a mount command. (The client asks the server (rpcbind) which port the NFS server is using, the client connects to the NFS server (nfsd), nfsd passes the request to mountd)

If all goes well, users on the client machine can then view and interact with mounted filesystems on the server within the parameters permitted.

Note that automation of the NFS mounting process may take place, perhaps by using /etc/fstab or automounting facilities.

During the development of the ONC protocol (called SunRPC at the time), only Apollo's Network Computing System (NCS) offered comparable functionality. Two competing groups developed over fundamental differences in the two remote procedure call systems. Arguments focused on the method for data-encoding – ONC's External Data Representation (XDR) always rendered integers in big-endian order, even if both peers of the connection had little-endian machine-architectures, whereas NCS's method attempted to avoid byte-swap whenever two peers shared a common endianness in their machine-architectures. An industry-group called the Network Computing Forum formed (March 1987) in an (ultimately unsuccessful) attempt to reconcile the two network-computing environments.

Later,[when?] Sun and AT&T announced they would jointly develop AT&T's UNIX System V Release 4. This caused many of AT&T's other licensees of UNIX System V to become concerned that this would put Sun in an advantaged position, and it ultimately led to Digital Equipment, HP, IBM, and others forming the Open Software Foundation (OSF) in 1988. Ironically, Sun and AT&T had previously competed over Sun's NFS versus AT&T's Remote File System (RFS), and the quick adoption of NFS over RFS by Digital Equipment, HP, IBM, and many other computer vendors tipped the majority of users in favor of NFS. NFS interoperability was aided by events called "Connectathons" starting in 1986 that allowed vendor-neutral testing of implementations with each other.[10] OSF adopted the Distributed Computing Environment (DCE) and the Distributed File System (DFS) over Sun/ONC RPC and NFS. DFS used DCE as the RPC, and DFS derived from the Andrew File System (AFS); DCE itself derived from a suite of technologies, including Apollo's NCS and Kerberos.[citation needed]

Sun Microsystems and the Internet Society (ISOC) reached an agreement to cede "change control" of ONC RPC so that the ISOC's engineering-standards body, the Internet Engineering Task Force (IETF), could publish standards documents (RFCs) related to ONC RPC protocols and could extend ONC RPC. OSF attempted to make DCE RPC an IETF standard, but ultimately proved unwilling to give up change control. Later, the IETF chose to extend ONC RPC by adding a new authentication flavor based on GSSAPI, RPCSEC GSS, in order to meet IETF's requirements that protocol standards have adequate security.

Later, Sun and ISOC reached a similar agreement to give ISOC change control over NFS, although writing the contract carefully to exclude NFS version 2 and version 3. Instead, ISOC gained the right to add new versions to the NFS protocol, which resulted in IETF specifying NFS version 4 in 2003.

By the 21st century, neither DFS nor AFS had achieved any major commercial success as compared to CIFS or NFS. IBM, which had previously acquired the primary commercial vendor of DFS and AFS, Transarc, donated most of the AFS source code to the free-software community in 2000. The OpenAFS project lives on. In early 2005, IBM announced end-of-sale for AFS and DFS.

In January 2010 Panasas proposed an NFSv4.1 based on their Parallel NFS (pNFS) technology; they claimed it improved data-access parallelism[11] capability. The NFSv4.1 protocol defines a method of separating the file system metadata from file data location; it goes beyond the simple name/data separation by striping the data amongst a set of data servers. This differs from the traditional NFS server which holds the names of files and their data under the single umbrella of the server. Some products provide multi-node NFS servers, but the participation of the client in separation of meta-data and data is limited.

The NFSv4.1 pNFS server is a collection of server resources or components; these are assumed to be controlled by the meta-data server.

The pNFS client still accesses a single meta-data server for traversal or interaction with the namespace; when the client moves data to and from the server it may directly interact with the set of data servers belonging to the pNFS server collection. The NFSv4.1 client can be enabled as a direct participant in the exact location of file data and to avoid solitary interaction with a single NFS server when moving data.