NFS: Network File System
`Version 3 Protocol Speci(cid:68)cation
`
`Comments to:
`sun!eng!nfs3
`nfs3@Eng.sun.com
`
`February 16, 1994
`
`microsystems
`
`ONC™ Technologies
`2550 Garcia Avenue
`Mountain View, CA 94043 USA
`
`1 of 98
`
` CROSSROADS EXHIBIT 2048
`Oracle Corp., et al v. Crossroads Systems, Inc.
` IPR2014-01207 and IPR2014-1209
`
`

`

`2/16/94
`
`Network File System Version 3 Protocol Specification
`
`Copyright 1993, 1994 Sun Microsystems, Inc. Printed in the United States of America. All rights reserved.
`
`This specification is protected by copyright and is distributed under the following conditions:
`
`The NFS Version 3 Protocol Specification is made available for your use provided that you include this provision and
`copyright notice on all copies made.
`
`Without express written consent of Sun Microsystems, Inc. (“Sun”), the names of Sun and any of its subsidiaries and
`affiliates may not be used in advertising or publicity pertaining to the distribution or use of this Specification as per-
`mitted herein.
`
`THIS SPECIFICATION IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND INCLUDING, BUT NOT
`LIMITED TO, THE WARRANTIES OF DESIGN, MERCHANTABILITY AND FITNESS FOR A PARTICULAR
`PURPOSE, NONINFRINGEMENT, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRAC-
`TICE. THIS SPECIFICATION IS NOT PROVIDED WITH ANY SUPPORT, AND SUN IS UNDER NO OBLIGA-
`TION TO ASSIST IN ITS USE, MODIFICATION, OR ENHANCEMENT.
`
`SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES SHALL HAVE NO LIABILITY WITH RESPECT TO
`THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS, OR ANY OTHER INTELLECTUAL PROPERTY
`RIGHTS OF ANY THIRD PARTIES BY THIS SPECIFICATION OR ITS USE THEREOF, NOR SHALL SUN OR
`ANY OF ITS SUBSIDIARIES OR AFFILIATES BE LIABLE FOR ANY LOST REVENUE OR PROFITS OR OTH-
`ER SPECIAL, INDIRECT AND CONSEQUENTIAL DAMAGES, EVEN IF SUN HAS BEEN ADVISED OF THE
`POSSIBILITY OF SUCH DAMAGES.
`
`Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the
`Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19.
`
`2
`2 of 98
`
`Version 3
`
`

`

`Network File System Version 3 Protocol Specification
`
`2/16/94
`
`Table of Contents
`
`Introduction
`Scope of the NFS version 3 protocol
`Useful terms
`Remote Procedure Call
`External Data Representation
`Authentication and Permission Checking
`Philosophy
`Changes from the NFS version 2 protocol
`RPC Information
`Authentication
`Constants
`Transport address
`Sizes
`Basic Data Types
`Defined Error Numbers
`Server Procedures
`NULL: Do nothing
`GETATTR: Get file attributes
`SETATTR: Set file attributes
`LOOKUP: Lookup filename
`ACCESS: Check Access Permission
`READLINK: Read from symbolic link
`READ: Read From file
`WRITE: Write to file
`CREATE: Create a file
`MKDIR: Create a directory
`SYMLINK: Create a symbolic link
`MKNOD: Create a special device
`REMOVE: Remove a File
`RMDIR: Remove a Directory
`RENAME: Rename a File or Directory
`LINK: Create Link to an object
`READDIR: Read From Directory
`READDIRPLUS: Extended read from directory
`FSSTAT: Get dynamic file system information
`FSINFO: Get static file system Information
`PATHCONF: Retrieve POSIX information
`COMMIT: Commit cached data on a server to stable storage
`Implementation issues
`Multiple version support
`Server/client relationship
`Path name interpretation
`Permission issues
`
`Version 3
`
`1
`3 of 98
`
`1
`1
`1
`2
`2
`3
`3
`5
`7
`7
`7
`7
`7
`7
`9
`16
`18
`19
`20
`22
`24
`26
`28
`30
`33
`36
`38
`40
`43
`45
`47
`49
`51
`54
`57
`59
`62
`64
`67
`67
`67
`67
`67
`
`

`

`2/16/94
`
`Network File System Version 3 Protocol Specification
`
`Duplicate request cache
`File name component handling
`Synchronous modifying operations
`Stable storage
`Lookups and name resolution
`Adaptive retransmission
`Caching policies
`Stable versus unstable writes
`32 bit clients/servers and 64 bit clients/servers
`Appendix I: Mount protocol
`RPC Information
`Authentication
`Constants
`Transport address
`Sizes
`Basic Data Types
`Server Procedures
`Null: Do nothing
`Mount: Add mount entry
`Dump: Return mount entries
`Unmount: Remove mount entry
`Unmount all: Remove all mount entries
`Export: Return export list
`Appendix II: Lock manager protocol
`RPC Information
`Authentication
`Constants
`Transport Address
`Basic Data Types
`NLM Procedures
`NULL: Do nothing
`Implementation issues
`Appendix III: Bibliography
`Index
`
`68
`69
`69
`69
`70
`70
`70
`70
`71
`73
`74
`74
`74
`74
`74
`74
`75
`76
`77
`78
`79
`80
`81
`83
`84
`84
`84
`84
`84
`87
`88
`89
`91
`93
`
`2
`4 of 98
`
`Version 3
`
`

`

`Network File System Version 3 Protocol Specification
`
`2/16/94
`
`Introduction
`
`The Sun Network File System (NFS™) protocol provides transparent remote access to shared file systems across net-
`works. The NFS protocol is designed to be machine, operating system, network architecture, and transport protocol
`independent. This independence is achieved through the use of Remote Procedure Call (RPC) primitives built on top
`of an eXternal Data Representation (XDR). Implementations of the NFS version 2 protocol exist for a variety of ma-
`chines, from personal computers to supercomputers. The initial version of the NFS protocol is specified in the Network
`File System specification [RFC1094]. A description of the initial implementation can be found in [Sandberg].
`
`The supporting MOUNT protocol performs the operating system-specific functions that allow clients to attach remote
`directory trees to a point within the local file system. The mount process also allows the server to grant remote access
`privileges to a restricted set of clients via export control.
`
`The Lock Manager provides support for file locking when used in the NFS environment. The Network Lock Manager
`(NLM) protocol isolates the inherently stateful aspects of file locking into a separate protocol.
`
`A complete description of the above protocols and their implementation is to be found in [X/OpenNFS].
`
`The purpose of this document is to:
`•
`Specify the NFS version 3 protocol
`•
`Describe semantics of the protocol through annotation and description of intended implementation
`•
`Specify the MOUNT version 3 protocol
`•
`Briefly describe the changes between the NLM version 3 protocol and the NLM version 4 protocol.
`
`The normative text is the description of the RPC procedures and arguments and results, which defines the over-the-
`wire protocol, and the semantics of those procedures. The material describing implementation practice aids the under-
`standing of the protocol specification and describes some possible implementation issues and solutions. It is not pos-
`sible to describe all implementations and the UNIX® operating system implementation of the NFS version 3 protocol
`is most often used to provide examples. Given that, the implementation discussion does not bear the authority of the
`description of the over-the wire protocol itself.
`
`Scope of the NFS version 3 protocol
`
`This revision of the NFS protocol addresses new requirements. The need to support larger files and file systems has
`prompted extensions to allow 64 bit file sizes and offsets. The revision enhances security by adding support for an
`access check to be done on the server. Performance modifications are of three types.
`1. First, the number of over-the-wire packets for a given set of file operations is reduced by returning file
`attributes on every operation, thus decreasing the number of calls to get modified attributes.
`2. Second, the write throughput bottleneck caused by the synchronous definition of write in the NFS version
`2 protocol has been addressed by adding support so that the NFS server can do unsafe writes. Unsafe
`writes are writes which have not been committed to stable storage before the operation returns. This spec-
`ification defines a method for committing these unsafe writes to stable storage in a reliable way.
`3. Third, limitations on transfer sizes have been relaxed.
`
`The ability to support multiple versions of a protocol in RPC will allow implementors of the NFS version 3 protocol
`to define clients and servers that provide backwards compatibility with the existing installed base of NFS version 2
`protocol implementations.
`
`The extensions described here represent an evolution of the existing NFS protocol and most of the design features of
`NFS described in [Sandberg] persist. See Changes from the NFS version 2 protocol on page 5 for a more detailed sum-
`mary of the changes introduced by this revision.
`
`Useful terms
`
`In this specification, a server is a machine that provides resources to the network; a client is a machine that accesses
`
`™ NFS is a registered trademark of Sun Microsystems, Inc.
`® UNIX is a registered trademark of UNIX System Laboratories.
`
`Version 3
`
`1
`5 of 98
`
`

`

`2/16/94
`
`Network File System Version 3 Protocol Specification
`
`resources over the network; a user is a person logged in on a client; anapplication is a program that executes on a
`client.
`
`Remote Procedure Call
`
`The Sun Remote Procedure Call specification provides a procedure-oriented interface to remote services. Each server
`supplies a program, which is a set of procedures. The NFS service is one such program. The combination of host ad-
`dress, program number, version number, and procedure number specify one remote service procedure. Servers can
`support multiple versions of a program by using different protocol version numbers.
`
`The NFS protocol was designed to not require any specific level of reliability from its lower levels so it could poten-
`tially be used on many underlying transport protocols. The NFS service is based on RPC which provides the abstrac-
`tion above lower level network and transport protocols.
`
`The rest of this document assumes the NFS environment is implemented on top of Sun RPC, which is specified in
`[RFC1057]. A complete discussion is found in [Corbin].
`
`External Data Representation
`
`The eXternal Data Representation (XDR) specification provides a standard way of representing a set of data types on
`a network. This solves the problem of different byte orders, structure alignment, and data type representation on dif-
`ferent, communicating machines.
`
`In this document, the RPC Data Description Language is used to specify the XDR format parameters and results to
`each of the RPC service procedures that an NFS server provides. The RPC Data Description Language is similar to
`declarations in the C programming language. A few new constructs have been added. The notation:
`string name[SIZE];
`string data<DSIZE>;
`
`defines name, which is a fixed size block of SIZE bytes, and data, which is a variable sized block of up to DSIZE
`bytes. This notation indicates fixed-length arrays and arrays with a variable number of elements up to a fixed maxi-
`mum. A variable-length definition with no size specified means there is no maximum size for the field.
`
`The discriminated union definition:
`union example switch (enum status) {
`case OK:
`struct {
`filename
`filename
`integer
`
`file1;
`file2;
`count;
`
`}
`case ERROR:
`struct {
`errstat
`integer
`
`}
`default:
`void;
`
`}
`
`error;
`errno;
`
`defines a structure where the first thing over the network is an enumeration type called status. If the value of
`status is OK, the next thing on the network will be the structure containing file1, file2, and count. Else, if
`the value of status is ERROR, the next thing on the network will be a structure containing error and errno. If
`the value of status is neither OK nor ERROR, then there is no more data in the structure.
`
`The XDR type, hyper, is an 8 byte (64 bit) quantity. It is used in the same way as the integer type. For example:
`hyper
`foo;
`unsigned hyper
`bar;
`
`2
`6 of 98
`
`Version 3
`
`

`

`Network File System Version 3 Protocol Specification
`
`2/16/94
`
`foo is an 8 byte signed value, while bar is an 8 byte unsigned value.
`
`Although RPC/XDR compilers exist to generate client and server stubs from RPC Data Description Language input,
`NFS implementations do not require their use. Any software that provides equivalent encoding and decoding to the
`canonical network order of data defined by XDR can be used to interoperate with other NFS implementations.
`
`XDR is described in [RFC1014].
`
`Authentication and Permission Checking
`
`The RPC protocol includes a slot for authentication parameters on every call. The contents of the authentication pa-
`rameters are determined by the type of authentication used by the server and client. A server may support several dif-
`ferent flavors of authentication at once. The AUTH_NONE flavor provides null authentication, that is, no authentication
`information is passed. The AUTH_UNIX flavor provides UNIX-style user id, group id, and groups with each call. The
`AUTH_DES flavor provides DES-encrypted authentication parameters based on a network-wide name, with session
`keys exchanged via a public key scheme. The AUTH_KERB flavor provides DES encrypted authentication parameters
`based on a network-wide name with session keys exchanged via Kerberos secret keys.
`
`The NFS server checks permissions by taking the credentials from the RPC authentication information in each remote
`request. For example, using the AUTH_UNIX flavor of authentication, the server gets the user’s effective user id, ef-
`fective group id and groups on each call, and uses them to check access. Using user ids and group ids implies that the
`client and server either share the same id list or do local user and group id mapping. Servers and clients must agree on
`the mapping from user to uid and from group to gid, for those sites that do not implement a consistent user id and group
`id space. In practice, such mapping is typically performed on the server, following a static mapping scheme or a map-
`ping established by the user from a client at mount time.
`
`The AUTH_DES and AUTH_KERB style of authentication is based on a network-wide name. It provides greater secu-
`rity through the use of DES encryption and public keys in the case of AUTH_DES, and DES encryption and Kerberos
`secret keys (and tickets) in the AUTH_KERB case. Again, the server and client must agree on the identity of a particular
`name on the network, but the name to identity mapping is more operating system independent than the uid and gid
`mapping in AUTH_UNIX. Also, because the authentication parameters are encrypted, a malicious user must know an-
`other users network password or private key to masquerade as that user. Similarly, the server returns a verifier that is
`also encrypted so that masquerading as a server requires knowing a network password.
`
`The NULL procedure typically requires no authentication.
`
`Philosophy
`
`This specification defines the NFS version 3 protocol, that is the over-the-wire protocol by which a client accesses a
`server. The protocol provides a well-defined interface to a server’s file resources. A client or server implements the
`protocol and provides a mapping of the local file system semantics and actions into those defined in the NFS version
`3 protocol. Implementations may differ to varying degrees, depending on the extent to which a given environment can
`support all the operations and semantics defined in the NFS version 3 protocol. Although implementations exist and
`are used to illustrate various aspects of the NFS version 3 protocol, the protocol specification itself is the final descrip-
`tion of how clients access server resources.
`
`Because the NFS version 3 protocol is designed to be operating-system independent, it does not necessarily match the
`semantics of any existing system. Server implementations are expected to make a best effort at supporting the protocol.
`If a server cannot support a particular protocol procedure, it may return the error, NFS3ERR_NOTSUP, that indicates
`that the operation is not supported. For example, many operating systems do not support the notion of a hard link. A
`server that cannot support hard links should return NFS3ERR_NOTSUP in response to a LINK request. FSINFO de-
`scribes the most commonly unsupported procedures in the properties bit map. Alternatively, a server may not na-
`tively support a given operation, but can emulate it in the NFS version 3 protocol implementation to provide greater
`functionality.
`
`In some cases, a server can support most of the semantics described by the protocol but not all. For example, the
`ctime field in the fattr structure gives the time that a file’s attributes were last modified. Many systems do not
`keep this information. In this case, rather than not support the GETATTR operation, a server could simulate it by re-
`turning the last modified time in place of ctime. Servers must be careful when simulating attribute information be-
`
`Version 3
`
`3
`7 of 98
`
`

`

`2/16/94
`
`Network File System Version 3 Protocol Specification
`
`cause of possible side effects on clients. For example, many clients use file modification times as a basis for their cache
`consistency scheme.
`
`NFS servers are dumb and NFS clients are smart. It is the clients that do the work required to convert the generalized
`file access that servers provide into a file access method that is useful to applications and users. In the LINK example
`given above, a UNIX client that received an NFS3ERR_NOTSUP error from a server would do the recovery necessary
`to either make it look to the application like the link request had succeeded or return a reasonable error. In general, it
`is the burden of the client to recover.
`
`The NFS version 3 protocol assumes a stateless server implementation. Statelessness means that the server does not
`need to maintain state about any of its clients in order to function correctly. Stateless servers have a distinct advantage
`over stateful servers in the event of a crash. With stateless servers, a client need only retry a request until the server
`responds; the client does not even need to know that the server has crashed. See additional comments in Duplicate
`request cache on page 68.
`
`For a server to be useful, it holds nonvolatile state: data stored in the file system. Design assumptions in the NFS ver-
`sion 3 protocol regarding flushing of modified data to stable storage reduce the number of failure modes in which data
`loss can occur. In this way, NFS version 3 protocol implementations can tolerate transient failures, including transient
`failures of the network. In general, server implementations of the NFS version 3 protocol cannot tolerate a non-tran-
`sient failure of the stable storage itself. However, there exist fault tolerant implementations which attempt to address
`such problems.
`
`That is not to say that an NFS version 3 protocol server can’t maintain noncritical state. In many cases, servers will
`maintain state (cache) about previous operations to increase performance. For example, a client READ request might
`trigger a read–ahead of the next block of the file into the server’s data cache in the anticipation that the client is doing
`a sequential read and the next client READ request will be satisfied from the server’s data cache instead of from the
`disk. Read-ahead on the server increases performance by overlapping server disk I/O with client requests. The impor-
`tant point here is that the read–ahead block is not necessary for correct server behavior. If the server crashes and loses
`its memory cache of read buffers, recovery is simple on reboot—clients will continue read operations retrieving data
`from the server disk.
`
`Most data-modifying operations in the NFS protocol are synchronous. That is, when a data modifying procedure re-
`turns to the client, the client can assume that the operation has completed and any modified data associated with the
`request is now on stable storage. For example, a synchronous client WRITE request may cause the server to update
`data blocks, file system information blocks, and file attribute information—the latter information is usually referred to
`as metadata. When the WRITE operation completes, the client can assume that the write data is safe and discard it.
`This is a very important part of the stateless nature of the server. If the server did not flush dirty data to stable storage
`before returning to the client, the client would have no way of knowing when it was safe to discard modified data. The
`following data modifying procedures are synchronous: WRITE (with stable flag set to FILE_SYNC), CREATE,
`MKDIR, SYMLINK, MKNOD, REMOVE, RMDIR, RENAME, LINK, and COMMIT.
`
`The NFS version 3 protocol introduces safe asynchronous writes on the server, when the WRITE procedure is used in
`conjunction with the COMMIT procedure. The COMMIT procedure provides a way for the client to flush data from pre-
`vious asynchronous WRITE requests on the server to stable storage and to detect whether it is necessary to retransmit
`the data. See the procedure descriptions of WRITE on page 30 and COMMIT on page 64.
`
`The LOOKUP procedure is used by the client to traverse multicomponent file names (pathnames). Each call to LOOKUP
`is used to resolve one segment of a pathname. There are two reasons for restricting LOOKUP to a single segment: it is
`hard to standardize a common format for hierarchical file names and the client and server may have different mappings
`of pathnames to file systems. This would imply that either the client must break the path name at file system attachment
`points, or the server must know about the client’s file system attachment points. In NFS version 3 protocol implemen-
`tations, it is the client that constructs the hierarchical file name space using mounts to build a hierarchy. Support util-
`ities, such as the Automounter, provide a way to manage a shared, consistent image of the file name space while still
`being driven by the client mount process.
`
`Clients can perform caching in varied manner. The general practice with the NFS version 2 protocol was to implement
`a time-based client-server cache consistency mechanism. It is expected NFS version 3 protocol implementations will
`use a similar mechanism. The NFS version 3 protocol has some explicit support, in the form of additional attribute
`
`4
`8 of 98
`
`Version 3
`
`

`

`Network File System Version 3 Protocol Specification
`
`2/16/94
`
`information to eliminate explicit attribute checks. However, caching is not required, nor is any caching policy defined
`by the protocol. Neither the NFS version 2 protocol nor the NFS version 3 protocol provide a means of maintaining
`strict client-server consistency (and, by implication, consistency across client caches).
`
`Changes from the NFS version 2 protocol
`
`The ROOT and WRITECACHE procedures have been removed. A MKNOD procedure has been defined to allow the cre-
`ation of special files, eliminating the overloading of CREATE. Caching on the client is not defined nor dictated by the
`NFS version 3 protocol, but additional information and hints have been added to the protocol to allow clients that im-
`plement caching to manage their caches more effectively. Procedures that affect the attributes of a file or directory may
`now return the new attributes after the operation has completed to optimize out a subsequent GETATTR used in vali-
`dating attribute caches. In addition, operations that modify the directory in which the target object resides return the
`old and new attributes of the directory to allow clients to implement more intelligent cache invalidation procedures.
`The ACCESS procedure provides access permission checking on the server, the FSSTAT procedure returns dynamic
`information about a file system, the FSINFO procedure returns static information about a file system and server, the
`READDIRPLUS procedure returns file handles and attributes in addition to directory entries, and the PATHCONF pro-
`cedure returns POSIX pathconf information about a file.
`
`Below is a list of the important changes between the NFS version 2 protocol and the NFS version 3 protocol.
`File handle size
`The file handle has been increased to a variable-length array of 64 bytes maximum from a fixed array of 32
`bytes. This addresses some known requirements for a slightly larger file handle size. The file handle was
`converted from fixed length to variable length to reduce local storage and network bandwidth requirements
`for systems which do not utilize the full 64 bytes of length.
`Maximum data sizes
`The maximum size of a data transfer used in the READ and WRITE procedures is now set by values in the
`FSINFO return structure. In addition, preferred transfer sizes are returned by FSINFO. The protocol does
`not place any artificial limits on the maximum transfer sizes. Filenames and pathnames are now specified as
`strings of variable length. The actual length restrictions are determined by the client and server implemen-
`tations as appropriate. The protocol does not place any artificial limits on the length. The error,
`NFS3ERR_NAMETOOLONG, is provided to allow the server to return an indication to the client that it re-
`ceived a pathname that was too long for it to handle.
`Error return
`Error returns in some instances now return data (for example, attributes). nfsstat3 now defines the full
`set of errors that can be returned by a server. No other values are allowed.
`File type
`The file type now includes NF3CHR and NF3BLK for special files. Attributes for these types include sub-
`fields for UNIX major and minor devices numbers. NF3SOCK and NF3FIFO are now defined for sockets
`and fifos in the file system.
`File attributes
`The blocksize (the size in bytes of a block in the file) field has been removed. The mode field no longer
`contains file type information. The size and fileid fields have been widened to eight-byte unsigned in-
`tegers from four-byte integers. Major and minor device information is now presented in a distinct structure.
`The blocks field name has been changed to used and now contains the total number of bytes used by the
`file. It is also an eight-byte unsigned integer.
`Set file attributes
`In the NFS version 2 protocol, the settable attributes were represented by a subset of the file attributes struc-
`ture; the client indicated those attributes which were not to be modified by setting the corresponding field
`to -1, overloading some unsigned fields. The set file attributes structure now uses a discriminated union for
`each field to tell whether or how to set that field. The atime and mtime fields can be set to either the server’s
`current time or a time supplied by the client.
`LOOKUP
`The LOOKUP return structure now includes the attributes for the directory searched.
`
`Version 3
`
`5
`9 of 98
`
`

`

`2/16/94
`
`Network File System Version 3 Protocol Specification
`
`ACCESS
`An ACCESS procedure has been added to allow an explicit over-the-wire permissions check. This addresses
`known problems with the superuser id mapping feature in many server implementations (where, due to map-
`ping of root user, unexpected permission denied errors could occur while reading from or writing to a file).
`This also removes the assumption which was made in the NFS version 2 protocol that access to files was
`based solely on UNIX style mode bits.
`READ
`The reply structure includes a Boolean that is TRUE if the end–of–file was encountered during the READ.
`This allows the client to correctly detect end-of-file.
`WRITE
`The beginoffset and totalcount fields were removed from the WRITE arguments. The reply now
`includes a count so that the server can write less than the requested amount of data, if required. An indicator
`was added to the arguments to instruct the server as to the level of cache synchronization that is required by
`the client.
`CREATE
`An exclusive flag and a create verifier was added for the exclusive creation of regular files.
`MKNOD
`This procedure was added to support the creation of special files. This avoids overloading fields of CREATE
`as was done in some NFS version 2 protocol implementations.
`READDIR
`The READDIR arguments now include a verifier to allow the server to validate the cookie. The cookie is
`now a 64 bit unsigned integer instead of the 4 byte array which was used in the NFS version 2 protocol.
`This will help to reduce interoperability problems.
`READDIRPLUS
`This procedure was added to return file handles and attributes in an extended directory list.
`FSINFO
`FSINFO was added to provide nonvolatile information about a file system. The reply includes preferred and
`maximum read transfer size, preferred and maximum write transfer size, and flags stating whether links or
`symbolic links are supported. Also returned are preferred transfer size for READDIR procedure replies, serv-
`er time granularity, and whether times can be set in a SETATTR request.
`FSSTAT
`FSSTAT was added to provide volatile information about a file system, for use by utilities such as df(1). The
`reply includes the total size and free space in the file system specified in bytes, the total number of files and
`number of free file slots in the file system, and an estimate of time between file system modifications (for
`use in cache consistency checking algorithms).
`COMMIT
`The COMMIT procedure provides the synchronization mechanism to be used with asynchronous WRITE op-
`erations.
`
`6
`10 of 98
`
`Version 3
`
`

`

`Network File System Version 3 Protocol Specification
`
`2/16/94
`
`RPC Information
`
`Authentication
`
`The NFS service uses AUTH_NONE in the NULL procedure. AUTH_UNIX, AUTH_DES, or AUTH_KERB are used for
`all other procedures. Other authentication types may be supported in the future.
`
`Constants
`
`These are the RPC constants needed to call the NFS Version 3 service. They are given in decimal.
`PROGRAM 100003
`VERSION 3
`
`Transport address
`
`NFS is normally supported over the UDP protocol. It uses port 2049, the same as the NFS version 2 protocol.
`
`Sizes
`
`These are the sizes, given in decimal bytes, of various XDR structures used in the NFS version 3 protocol:
`NFS3_FHSIZE 64
`The maximum size in bytes of the opaque file handle.
`NFS3_COOKIEVERFSIZE 8
`The size in bytes of the opaque cookie verifier passed by READDIR and READDIRPLUS.
`NFS3_CREATEVERFSIZE 8
`The size in bytes of the opaque verifier used for exclusive CREATE.
`NFS3_WRITEVERFSIZE 8
`The size in bytes of the opaque verifier used for asynchronous WRITE.
`
`Basic Data Types
`
`The following XDR definitions are basic definitions that are used in other structures.
`
`uint64
`typedef unsigned hyper
`
`uint64;
`
`int64
`typedef hyper
`
`uint32
`typedef unsigned long
`
`int32
`typedef long
`
`filename3
`typedef string
`
`nfspath3
`typedef string
`
`fileid3
`typedef uint64
`
`cookie3
`typedef uint64
`
`cookieverf3
`typedef opaque
`
`int64;
`
`uint32;
`
`int32;
`
`filename3<>;
`
`nfspath3<>;
`
`fileid3;
`
`cookie3;
`
`cookieverf3[NFS3_COOKIEVERFSIZE];
`
`Version 3
`
`7
`11 of 98
`
`

`

`2/16/94
`
`Network File System Version 3 Protocol Specification
`
`createverf3
`typedef opaque
`
`writeverf3
`typedef opaque
`
`uid3
`typedef uint32
`
`gid3
`typedef uint32
`
`size3
`typedef uint64
`
`offset3
`typedef uint64
`
`mode3
`typedef uint32
`
`count3
`typedef uint32
`
`nfsstat3
`enum nfsstat3 {
`NFS3_OK
`NFS3ERR_PERM
`NFS3ERR_NOENT
`NFS3ERR_IO
`NFS3ERR_NXIO
`NFS3ERR_ACCES
`NFS3ERR_EXIST
`NFS3ERR_XDEV
`NFS3ERR_NODEV
`NFS3ERR_NOTDIR
`NFS3ERR_ISDIR
`NFS3ERR_INVAL
`NFS3ERR_FBIG
`NFS3ERR_NOSPC
`NFS3ERR_ROFS
`NFS3ERR_MLINK
`NFS3ERR_NAMETOOLONG
`NFS3ERR_NOTEMPTY
`NFS3ERR_DQUOT
`NFS3ERR_STALE
`NFS3ERR_REMOTE
`NFS3ERR_BADHANDLE
`NFS3ERR_NOT_SYNC
`NFS3ERR_BAD_COOKIE
`NFS3ERR_NOTSUPP
`NFS3ERR_TOOSMALL
`NFS3ERR_SERVERFAULT
`NFS3ERR_BADTYPE
`NFS3ERR_JUKEBOX
`
`};
`
`createverf3[NFS3_CREATEVERFSIZE];
`
`writeverf3[NFS3_WRITEVERFSIZE];
`
`uid3;
`
`gid3;
`
`size3;
`
`offset3;
`
`mode3;
`
`count3;
`
`= 0,
`= 1,
`= 2,
`= 5,
`= 6,
`= 13,
`= 17,
`= 18,
`= 19,
`= 20,
`= 21,
`= 22,
`= 27,
`= 28,
`= 30,
`= 31,
`= 63,
`= 66,
`= 69,
`= 70,
`= 71,
`= 10001,
`= 10002,
`= 10003,
`= 10004,
`= 10005,
`= 10006,
`= 10007,
`= 10008
`
`The nfsstat3 type is returned with every procedure’s results except for the NULL procedure. A value of NFS3_OK
`
`8
`12 of 98
`
`Version 3
`
`

`

`Network File System Version 3 Protocol Specification
`
`2/16/94
`
`indicates that the call completed successfully. Any other value indicates that some error occurred on the call, as iden-
`tified by the error code. Note that the precise numeric encoding must be followed. No other values may be returned by
`a server. Servers are expected to make a best effort mapping of error conditions to the set of error codes defined. In
`addition, no error precedences are specified by this specification. Error precedences determine the error value that
`should be returned when more than one error applies in a given situation. The error precedence will be determined by
`the individual server implementation. If the client requires specific error precedences, it should check for the specific
`errors for itself.
`
`A description of each defined error follows.
`
`Defined Error Numbers
`NFS3_OK
`Indicates the call completed successfully.
`NFS3ERR_PERM
`Not owner. The operation was not allowed because the caller is either not a privileged user (root) or not the
`owner of the target of the operation.
`NFS3ERR_NOENT
`No such file or directory. The file or directory name specified does not exist.
`NFS3ERR_IO
`I/O error. A hard error (for example, a disk error) occurred while