NFS: Network File System Protocol specification
RFC 1094

Document Type RFC - Informational (March 1989; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1094 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                             Sun Microsystems, Inc.
Request for Comments: 1094                                    March 1989

            NFS: Network File System Protocol Specification

STATUS OF THIS MEMO

   This RFC describes a protocol that Sun Microsystems, Inc., and others
   are using.  A new version of the protocol is under development, but
   others may benefit from the descriptions of the current protocol, and
   discussion of some of the design issues.  Distribution of this memo
   is unlimited.

1. INTRODUCTION

   The Sun Network Filesystem (NFS) protocol provides transparent remote
   access to shared files across networks.  The NFS protocol is designed
   to be portable across different machines, operating systems, network
   architectures, and transport protocols.  This portability is achieved
   through the use of Remote Procedure Call (RPC) primitives built on
   top of an eXternal Data Representation (XDR).  Implementations
   already exist for a variety of machines, from personal computers to
   supercomputers.

   The supporting mount protocol allows the server to hand out remote
   access privileges to a restricted set of clients.  It performs the
   operating system-specific functions that allow, for example, to
   attach remote directory trees to some local file system.

1.1.  Remote Procedure Call

   Sun's Remote Procedure Call specification provides a procedure-
   oriented interface to remote services.  Each server supplies a
   "program" that is a set of procedures.  NFS is one such program.  The
   combination of host address, program number, and procedure number
   specifies one remote procedure.  A goal of NFS was to not require any
   specific level of reliability from its lower levels, so it could
   potentially be used on many underlying transport protocols, or even
   another remote procedure call implementation.  For ease of
   discussion, the rest of this document will assume NFS is implemented
   on top of Sun RPC, described in  RFC 1057, "RPC: Remote Procedure
   Call Protocol Specification".

1.2.  External Data Representation

   The eXternal Data Representation (XDR) standard provides a common way
   of representing a set of data types over a network.  The NFS Protocol

Sun Microsystems, Inc.                                          [Page 1]
RFC 1094                NFS: Network File System              March 1989

   Specification is written using the RPC data description language.
   For more information, see RFC 1014, "XDR: External Data
   Representation Standard".  Although automated RPC/XDR compilers exist
   to generate server and client "stubs", NFS does not require their
   use.  Any software that provides equivalent functionality can be
   used, and if the encoding is exactly the same it can interoperate
   with other implementations of NFS.

1.3.  Stateless Servers

   The NFS protocol was intended to be as stateless as possible.  That
   is, a server should not need to maintain any protocol state
   information about any of its clients in order to function correctly.
   Stateless servers have a distinct advantage over stateful servers in
   the event of a failure.  With stateless servers, a client need only
   retry a request until the server responds; it does not even need to
   know that the server has crashed, or the network temporarily went
   down.  The client of a stateful server, on the other hand, needs to
   either detect a server failure and rebuild the server's state when it
   comes back up, or cause client operations to fail.

   This may not sound like an important issue, but it affects the
   protocol in some unexpected ways.  We feel that it may be worth a bit
   of extra complexity in the protocol to be able to write very simple
   servers that do not require fancy crash recovery.  Note that even if
   a so-called "reliable" transport protocol such as TCP is used, the
   client must still be able to handle interruptions of service by re-
   opening connections when they time out.  Thus, a stateless protocol
   may actually simplify the  implementation.

   On the other hand, NFS deals with objects such as files and
   directories that inherently have state -- what good would a file be
   if it did not keep its contents intact?  The goal was to not
   introduce any extra state in the protocol itself.  Inherently
   stateful operations such as file or record locking, and remote
   execution,  were implemented as separate services, not described in
   this document.

   The basic way to simplify recovery was to make operations as
   "idempotent" as possible (so that they can potentially be repeated).
   Some operations in this version of the protocol did not attain this
   goal; luckily most of the operations (such as Read and Write) are
Show full document text