 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
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 > 192.168.1.254.3476097947 > \
192.168.1.252.2049: 144 lookup fh 32,0/224145 "test-file"
10:30:16.012010 eth0 > 192.168.1.254.3476097947 > \
192.168.1.252.2049: 144 lookup fh 32,0/224145 "test-file"
10:30:16.012729 eth0 < 192.168.1.252.2049 > \
192.168.1.254.3476097947: reply ok 128 lookup fh 32,0/224307 (DF)
10:30:16.012729 eth0 < 192.168.1.252.2049 > \
192.168.1.254.3476097947: reply ok 128 lookup fh 32,0/224307 (DF)
10:30:16.013124 eth0 > 192.168.1.254.3492875163 > \
192.168.1.252.2049: 140 read fh 32,0/224307 4096 bytes @ 0
10:30:16.013124 eth0 > 192.168.1.254.3492875163 > \
192.168.1.252.2049: 140 read fh 32,0/224307 4096 bytes @ 0
10:30:16.013650 eth0 < 192.168.1.252.2049 > \
192.168.1.254.3492875163: reply ok 108 read (DF)
10:30:16.013650 eth0 < 192.168.1.252.2049 > \
192.168.1.254.3492875163: 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.
Summary
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: ronald.mccarty@gte.net.
| 
