Cover V10, I10

Table 1


NFS: Part I, The Protocol

Ron McCarty

The Network File Server (NFS) protocol provides an open standard for giving clients remote access to file systems. NFS allows administrators to create centralized file systems that ease management tasks such as backups and virus checking. Large, centralized drivers are easier to maintain than many distributed small drives.

Besides lending itself to centralized storage, NFS has also proven itself useful in other applications such as diskless and thin clients, network clustering, and cross-platform interoperability applications.

A better understanding of the protocol and implementation considerations will ensure smooth operations of remote file access via NFS. This two-part article covers NFS -- the first part covers the protocol and design considerations, and the second part covers using NFS on Solaris and Linux.

In the Beginning...

The NFS protocol was originally designed by Sun and eventually released to the Internet with RFC 1094, "NFS: Network File System Protocol Specification" in 1989. It is interesting to note that Novell's strategy at the time was to perfect file services in a very closed manner, and although Sun had not, until the recent open source movement, been as open on network implementations, they did see the importance of interoperability with other systems.

RFC 1094 covered the original two specifications, but Version 3 was already under specification development as Sun released the original RFC. Version 3's specification is covered in RFC 1813, "NFS Version 3 Protocol Specification". Version 4 of the protocol is defined in RFC 3010, "NFS Version 4 Protocol".

NFS is widely deployed on all types of UNIX hosts, Microsoft and Novell networks, and IBM solutions such as AS400 and OS/390. Despite its not being known outside the network realm, it may be the most widely deployed platform-independent network file system.

UNIX Roots

Although NFS is not platform specific, it does have roots in UNIX; stated otherwise, the file hierarchy and access methods are very similar to the UNIX practice of handling file systems including structure, user and group identification, and file handling. For example, the NFS concept of file system follows the same structure of a UNIX file system and is directly mounted within it. When NFS is used by other operating systems, a method of mapping user identification, file permissions, and file access limitations must be used. Table 1 lists resources on popular implementations of the mapping.


NFS works within a client/server architecture. The client accesses file systems exported by the NFS server through the NFS mount point on the client. The access is typically transparent to the client application.

Unlike many client server communications, NFS uses remote procedure calls for communications. A typical client would connect to a well-known port and then use particulars of the protocol to request specific action. With the remote procedure call, however, the client creates the procedure call and then sends it to the server for execution. A detailed view of NFS is covered shortly.

As an example, consider the client that has mounted the directory usr2 into the local root file system:

/root/usr2/ --> remote:/root/usr/
Should the client application need to access the directory, it simply requests the directory and file name of the operating system. The operating system then provides access through the NFS client. For example, consider the simple UNIX command cd. cd is not aware of network protocols, but by using:

cd /root/usr2/
the cd places the working directory on the remote file system without the cd command (or the user, necessarily) knowing that the file system is remote.

When the NFS server receives the request, it will then determine that the user has access rights for the particular action requested and, assuming access permission, the NFS server will serve the file requested.

A Closer Look

From the client perspective, there are several steps that occur when a remote file system is mounted locally through NFS. As mentioned, the NFS client creates an RPC for the server to execute. Note that the client, under UNIX, is implemented as one program (the mount command), but the server is actually implemented as several programs with a port mapper, mount daemon, and NFS server being the minimum.

During initial communication with the server, the client mount command will communicate with the server's port mapper, which is listening on the known port 111. Most implementations of the client mount command will support multiple versions of NFS, which improves the likelihood of a common protocol between client and server. The mount command starts with the highest protocol supported, thus ensuring the common protocol is also the newest protocol supported by both client and server.

(Version 3 is probably the most deployed version of NFS, with NFS Version 4 support gaining slowly by most implementations, so the material covered is Version 3.)

The server's port mapper server will respond with the protocol supported as well as the port the mount daemon is running on. At this point, the client mount can connect to the mount daemon and issue the mount command via RPC to the server mount daemon. Once successfully completed, the client can then connect to the NFS server on port 2049 and, using one of the 20 RPCs as defined by RFC 1813 and summarized in the following table, to access the remote file system.

ACCESS -- Check access permission
COMMIT -- Commit cached data on a server to stable storage
CREATE -- Create a file
FSINFO -- Get static file system information
FSSTAT -- Get dynamic file system information
GETATTR -- Get file attributes
LINK -- Create link to an object
LOOKUP -- Lookup filename
MKDIR -- Create a directory
MKNOD -- Create a special device
READ -- Read file
READDIR -- Read From directory
READDIRPLUS -- Extended read from directory
READLINK -- Read symbolic link
REMOVE -- Remove a file
RENAME -- Rename a file or directory
RMDIR -- Remove a directory
SETATTR -- Set file attributes
SYMLINK -- Create a symbolic link
WRITE -- Write file

Most of the commands are very intuitive and, due to NFS's UNIX roots, most administrators recognize the commands. The following tcdump output shows the READ command created by the UNIX cat command to read the test-file file:

10:30:16.012010 eth0 > > \ 144 lookup  fh 32,0/224145 "test-file"
10:30:16.012010 eth0 > > \ 144 lookup fh 32,0/224145 "test-file"
10:30:16.012729 eth0 < > \ reply ok 128 lookup fh 32,0/224307 (DF)
10:30:16.012729 eth0 < > \ reply ok 128 lookup fh 32,0/224307 (DF)
10:30:16.013124 eth0 > > \ 140 read fh 32,0/224307 4096 bytes @ 0
10:30:16.013124 eth0 > > \ 140 read fh 32,0/224307 4096 bytes @ 0
10:30:16.013650 eth0 < > \ reply ok 108 read (DF)
10:30:16.013650 eth0 < > \ reply ok 108 read (DF)
NFS has traditionally been implemented over UDP, but TCP support is provided by the protocol specifications and supported by some versions of NFS. The greatest advantage TCP provides is the improvement of retransmissions on troublesome networks. (With UDP, an entire RPC message, made up of several UDP packets, must be retransmitted should a failure occur. With TCP only the dropped fragment is retransmitted.)

NFS Access

NFS implementations typically provide access rights through four methods: user and file attributes, share-level access, host-level access, and hybrids of the other methods.

User and file attributes rely on UNIX built-in support of user, group, and file access permissions. To ease management, user and group identifications should be uniform across NFS clients and servers. File permissions and access should be carefully considered as well. NFS can inadvertently provide access to files that was not planned with the original creation of the files.

Share-level access allows limiting the access to a specific activity regardless of the UNIX file ownership or permissions. For example, an NFS can be limited to read only. Most implementations of NFS will allow the share-level access to be further limited to particular users or groups. For example, grant read-only access to the group "human resources".

Host-level access allows file systems to be mounted only on particular hosts and is generally a good idea since file systems can easily be mounted by any host supporting NFS.

Hybrid access simply mixes the above methods (such as share-level access with particular user access). Another example is to only allow users from a particular host to access an NFS.


NFS, though not typical for a network protocol, provides an efficient method to providing remote file access to users. I've covered operation of the protocol in the first part of this two-part series. Next time, I will cover Linux and Solaris implementations of the protocol with examples and traces. Stay tuned.

Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. After completing his degree, Ronald McCarty started his network career as network administrator at the Schwaebisch Gmuend campus. Ronald McCarty works for Lucent Technologies as a senior systems engineer on a customer team responsible for a major telecommunications carrier. He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia. Ron can be reached at: