Network Working Group
`for Comments
`Request
`Category Informational
`
`1813
`
`Callaghan
`Pawlowski
`Staubach
`Sun Microsystems Inc
`June 1995
`
`NFS Version
`
`Protocol Specification
`
`Status of
`
`this Memo
`
`information for the Internet community
`This memo provides
`This memo does not specify an Internet standard of any kind
`this memo is unlimited
`Distribution of
`
`IESG Note
`
`Internet Engineering Steering Group comment please note that
`in creating or maintaining this
`the IETF is not
`involved
`This is the significance of
`the specification
`specification
`not being on the standards track
`
`Abstract
`
`protocol
`This paper
`This paper describes the NFS version
`provided so that people can write compatible
`implementations
`
`is
`
`Table of Contents
`
`11
`12
`1.3
`
`1.4
`
`1.5
`1.6
`17
`
`2.1
`22
`2.3
`24
`2.5
`
`2.6
`
`3.1
`32
`3.3.0
`
`protocol
`
`protocol
`
`Introduction
`the NFS version
`Scope of
`Useful
`terms
`Remote Procedure Call
`External Data Representation
`Authentication
`and Permission Checking
`Philosophy
`from the NES version
`Changes
`RPC Information
`Authentication
`Constants
`Transport address
`Sizes
`Basic Data Types
`Defined Error Numbers
`Server Procedures
`General comments
`General comments
`NULL Do nothing
`
`on attributes
`on filenames
`
`Callaghan el al
`
`Informational
`
`11
`
`14
`
`14
`
`14
`
`14
`
`14
`
`15
`
`17
`
`27
`
`30
`31
`
`Petitioner IBM – Ex. 1042, p. 1
`
`

`
`EEC 1813
`
`NFS Version
`
`Protocol
`
`June 1995
`
`331
`3.3.2
`3.3.3
`334
`335
`
`3.6
`337
`3.3.8
`339
`3.3.10
`3.11
`.3 12
`.3 13
`
`.3 14
`
`.3.15
`3316
`33 17
`3.3.18
`3.3.19
`3320
`3321
`
`41
`42
`43
`4.4
`45
`46
`47
`4.8
`
`4.9
`4.10
`4.11
`
`12
`
`4.13
`
`51
`1.1
`5.1.2
`5.1.3
`514
`5.15
`52
`520
`521
`5.2.2
`5.23
`5.2.4
`
`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
`file
`MKDIR Create
`directory
`SYMLINK Create
`symbolic link
`MKNOD Create
`special device
`REMOVE
`file
`Remove
`RMDIR Remove
`directory
`RENAME
`file or directory
`Rename
`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
`server
`issues
`Implementation
`Multiple version support
`Server/client
`relationship
`Path name
`interpretation
`Permission issues
`cache
`Duplicate request
`File name component handling
`Synchronous modifying operations
`Stable storage
`resolution
`Lookups and name
`Adaptive retransmission
`Caching policies
`Stable versus unstable writes
`32 bit clients/servers and 64 bit
`Mount protocol
`Appendix
`RPC Information
`Authentication
`Constants
`Transport address
`Sizes
`Basic Data Types
`Server Procedures
`NULL Do nothing
`MNT Add mount entry
`DUMP Return mount entries
`UMMT
`Remove mount entry
`UMNTALL
`Remove all mount entries
`
`to stable storage
`
`clients/servers
`
`32
`
`33
`
`37
`
`40
`
`44
`
`46
`
`49
`
`54
`58
`
`61
`
`63
`
`67
`
`69
`
`71
`
`74
`76
`
`80
`
`84
`
`86
`
`90
`
`92
`
`96
`
`96
`
`96
`
`97
`
`98
`
`99
`
`101
`
`101
`
`101
`
`102
`102
`
`102
`
`103
`
`104
`
`106
`
`106
`
`106
`
`106
`
`106
`
`106
`106
`
`107
`108
`
`109
`
`110
`
`111
`
`112
`
`Callaghan el al
`
`Informational
`
`2J
`
`Petitioner IBM – Ex. 1042, p. 2
`
`

`
`RFC 1813
`
`NFS version
`
`Protocol
`
`June 1995
`
`5.2.5
`
`6.1
`6.1.1
`6.1.2
`1.3
`6.1.4
`6.2
`6.2.0
`6.3
`3.1
`6.3.2
`
`10
`
`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
`64-bit offsets and lengths
`File handles
`Appendix III Bibliography
`Security Considerations
`Acknowledgements
`Authors Addresses
`
`Introduction
`
`113
`114
`
`114
`
`114
`
`114
`115
`115
`118
`
`120
`120
`
`120
`120
`
`122
`....125
`125
`126
`
`Sun
`remote access to shared
`NFS protocol provides transparent
`file systems across networks The NFS protocol
`is designed to be
`machine operating system network architecture
`and transport
`independent This independence
`is achieved through the
`protocol
`use of Remote Procedure Call RPC primitives built on top of an
`external Data Representation XDR Implementations of the NFS
`variety of machines
`protocol exist for
`version
`from personal
`The initial
`version of the NFS
`computers to supercomputers
`is specified in the Network File System Protocol
`protocol
`Specification RFC1O94
`description of the initial
`implementation can be found in Sandberg
`
`The supporting MOUNT protocol performs the operating
`functions that allow clients to attach remote
`system-specific
`point within the local
`file system The
`directory trees to
`mount process also allows the server to grant
`remote access
`restricted set of clients via export control
`privileges to
`
`for file locking when used in
`The Lock Manager provides support
`Lock Manager NLM protocol
`the NFS environment The Network
`isolates the inherently stateful aspects of file locking into
`separate protocol
`
`complete description of the above protocols and their
`implementation is to be found in X/OpenNFS
`
`The purpose of this document
`
`is to
`
`Callaghan el al
`
`Informational
`
`Page
`
`Petitioner IBM – Ex. 1042, p. 3
`
`

`
`RET
`
`1813
`
`NFS Version
`
`Protocol
`
`June 1995
`
`Specify the NES version
`
`protocol
`
`through annotation
`Describe semantics of
`the protocol
`and description of
`intended implementation
`
`Specify the MOUNT version
`
`protocol
`
`Briefly describe the changes between the NLM version
`and the NLM version
`protocol
`protocol
`
`the RPC procedures and
`The normative text
`is the description of
`and results which defines the over-the-wire protocol
`arguments
`those procedures The material describing
`and the semantics of
`implementation practice aids the understanding of
`the protocol
`specification and describes
`some possible implementation issues
`and solutions It
`is not possible to describe all
`implementations
`and the UNIX operating system implementation of
`the NES version
`is most often used to provide examples Given that
`protocol
`the
`implementation discussion does not bear
`the authority of
`the
`itself
`the over-the-wire protocol
`description of
`
`1.1 Scope of
`
`the NFS version
`
`protocol
`
`the NES protocol addresses new requirements
`This revision of
`The need to support
`files and file systems has prompted
`larger
`file sizes and offsets The revision
`to allow 64 bit
`extensions
`enhances security by adding support
`check
`for an access
`to be
`done on the server Performance modifications
`three
`are of
`types
`
`The number of over-the-wire packets for
`given
`file operations is reduced by returning file
`set of
`attributes on every operation thus decreasing the number
`of calls to get modified attributes
`
`The write throughput bottleneck caused by the synchronous
`definition of write in the NES version
`has been
`protocol
`so that
`the NES server can do
`addressed by adding support
`unsafe writes Unsafe writes are writes which have not
`been committed to stable storage before the operation
`returns
`method for
`This specification defines
`committing these unsafe writes to stable storage in
`reliable way
`
`Limitations on transfer sizes have
`
`been relaxed
`
`The ability to support multiple versions of
`the NFS version
`will allow implementors of
`
`protocol
`protocol
`
`in RPC
`to define
`
`Callaghan el al
`
`Informational
`
`4J
`
`Petitioner IBM – Ex. 1042, p. 4
`
`

`
`REC
`
`1813
`
`NFS Version
`
`Protocol
`
`June 1995
`
`clients and servers that provide backwards compatibility with
`the existing installed base of NFS version
`protocol
`implementations
`
`here represent an evolution of
`described
`The extensions
`and most of
`existing NFS protocol
`the design features of
`persist See Changes
`NFS protocol described
`in
`from the NFS version
`more
`on page 11
`for
`introduced by this revision
`detailed summary of
`
`protocol
`the changes
`
`the
`the
`
`1.2 Useful
`
`terms
`
`In this specification
`to the network
`resources
`the network
`resources over
`client
`an application is
`
`server
`machine that provides
`is
`client is
`machine that accesses
`user is
`person logged in on
`client
`program that executes on
`
`Remote Procedure Call
`
`The Sun Remote Procedure Call specification provides
`interface to remote services Each server
`procedureoriented
`program which is
`set of procedures The NFS
`supplies
`service is one such program The combination of host address
`program number version number and procedure number specify one
`Servers can support multiple versions
`remote service procedure
`program by using different protocol version numbers
`of
`
`require any specific level
`The NES protocol was designed to not
`of reliability from its lower
`levels so it could potentially be
`used on many underlying transport protocols The
`NES service is
`based on RPC which provides the abstraction above
`lower
`level
`network and transport protocols
`
`this document assumes the MRS environment
`The rest of
`implemented on top of Sun RPC which is specified in
`complete discussion is found in
`
`is
`
`1.4 External Data Representation
`
`xDR specification provides
`The external Data Representation
`network
`standard way of representing
`set of data types on
`This solves the problem of different byte orders structure
`alignment
`and data type representation on different
`communicating machines
`
`In this document
`is used to
`the RPC Data Description Language
`the RPC
`format parameters and results to each of
`specify the XDR
`service procedures that an NFS server provides The RPC Data
`
`Callaghan el al
`
`Informational
`
`Petitioner IBM – Ex. 1042, p. 5
`
`

`
`RFC 1813
`
`NFS version
`
`Protocol
`
`June 1995
`
`in the
`Description Language is similar to declarations
`few new constructs have been added
`prograumting language
`The notation
`
`string nameSIZE
`string datacDSIZE
`
`fixed size block of SIZE bytes and
`defines name which is
`data which is
`variable sized block of up to DSIZE bytes This
`notation indicates fixed-length arrays and arrays with
`fixed maximum
`variable number of elements up to
`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
`
`filel
`file2
`count
`
`case ERROR
`struct
`errstat
`integer
`
`default
`void
`
`error
`errno
`
`the network is an
`thing over
`structure where the first
`defines
`the value of status is OK
`enumeration type called status If
`the next
`thing on the network will be the structure containing
`file2 and count Else if
`filel
`the value of status is ERROR
`the next
`thing on the network will be
`structure containing
`the value of status is neither OK nor
`error and errno If
`then there is no nore data in the structure
`ERROR
`
`byte 64 bit quantity It
`The XDR type hyper
`is an
`in the same way as the integer type For example
`
`is used
`
`foo
`hyper
`unsigned hyper bar
`
`foo is an
`value
`
`byte signed value while bar is an
`
`byte unsigned
`
`Callaghan el al
`
`Informational
`
`Page
`
`Petitioner IBM – Ex. 1042, p. 6
`
`

`
`REC
`
`1813
`
`NFS Version
`
`Protocol
`
`June 1995
`
`to generate client and server
`Although RPC/XDR compilers exist
`input NFS
`stubs from RPC Data Description Language
`require their use Any software that
`implementations do not
`to the canonical
`and decoding
`provides equivalent encoding
`network order of data defined by XDR can be used to interoperate
`with other NFS implementations
`
`XDR is described
`
`in
`
`1.5 Authentication and Permission Checking
`
`includes
`for authentication parameters
`slot
`The RPC protocol
`on every call The contents of
`the authentication
`parameters are
`determined by the type of authentication used by the server and
`client
`flavors of
`server may support several different
`at once The AUTH
`NONE
`authentication
`flavor provides null
`is no authentication
`authentication that
`information is
`ID group
`passed
`The AUTH UNIX flavor provides UNIX-style user
`ID and groups with each call The AUTH DES
`flavor provides
`DES-encrypted authentication parameters based on
`network-wide
`public key scheme
`name with session keys exchanged via
`The
`AUTH
`KERR
`flavor provides
`DES encrypted authentication
`parameters based on
`network-wide name with session keys
`exchanged via Kerberos secret keys
`
`from
`The NFS server checks permissions by taking the credentials
`the RPC authentication
`information in each remote request For
`example
`using the AUTH_UNIX
`flavor of authentication the
`ID effective group ID and
`server gets the users effective user
`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
`to uid
`Servers and clients must agree on the mapping from user
`and from group to gid for
`those sites that do not
`implement
`ID and group ID space In practice
`consistent user
`such mapping
`is typically performed on the server
`static mapping
`following
`scheme or
`mapping established by the user
`from
`client at
`time
`mount
`
`is based on
`and AUTH_KERB style of authentication
`The AUTH_DES
`network-wide name It provides greater security 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_KERR case Again the server and client must agree on the
`particular name on the network but
`identity of
`the name to
`than the
`identity mapping is more operating system independent
`uid and gid mapping in AUTH_UNIX Also because the
`parameters are encrypted
`authentication
`malicious user must
`
`Callaghan el al
`
`Informational
`
`Petitioner IBM – Ex. 1042, p. 7
`
`

`
`RFC 1813
`
`NFS Version
`
`Protocol
`
`June 1995
`
`know another users network password or private key to masquerade
`as that user Similarly the server returns
`verifier that
`is
`also encrypted so that masquerading as
`server requires knowing
`network password
`
`The MULL procedure typically requires no authentication
`
`1.6 Philosophy
`
`protocol
`that
`This specification defines the NFS version
`is
`server
`the over-the-wire protocol by which
`client accesses
`servers
`well-defined interface to
`The protocol provides
`file resources
`and
`client or server implements the protocol
`file system semantics and
`the local
`provides
`mapping of
`protocol
`actions into those defined in the NFS version
`Implementations may differ
`to varying degrees depending
`given environment
`to which
`the
`extent
`can support all
`protocol
`operations and semantics defined in the NFS version
`Although implementations exist and are used to illustrate
`protocol
`the NFS version
`various aspects of
`the protocol
`specification itself
`is the final description of how clients
`resources
`access server
`
`on the
`
`the NFS version
`
`Because
`is designed to be
`protocol
`does not necessarily match the
`it
`operating-system independent
`semantics of any existing system Server
`implementations are
`best effort at supporting the protocol
`to make
`expected
`If
`particular protocol procedure it may
`server cannot
`support
`return the error NFS3ERRNOTSUP
`that
`indicates that
`the
`operation is not supported
`For example many operating systems
`hard link
`the notion of
`do not support
`server that cannot
`support hard links should return NFS3ERRNOTSUP in response to
`LINK request FSINFO describes the most commonly unsupported
`procedures in the properties bit map Alternatively
`server
`given operation but can emulate it
`may not natively support
`in the NFS version
`implementation to provide greater
`protocol
`functionality
`
`In some cases
`the semantics
`server can support most of
`by the protocol but not all For example
`described
`the ctime
`files
`field in the fattr structure gives the time that
`attributes were last modified Many systems do not keep
`this
`information In this case
`the GETATTR
`rather than not support
`operation
`server could simulate it
`by returning the last
`modified time in place of ctime
`Servers must be careful when
`simulating attribute information because of possible side
`on clients For example many clients use
`effects
`file
`modification times as
`basis for their cache consistency
`
`Callaghan el al
`
`Informational
`
`81
`
`Petitioner IBM – Ex. 1042, p. 8
`
`

`
`RET
`
`1813
`
`NFS Version
`
`Protocol
`
`June 1995
`
`scheme
`
`NFS servers are dumb and NFS clients are smart
`is the
`It
`clients that do the work required to convert
`the generalized
`file access
`file access method that
`that servers provide into
`and users In the LINK example given
`is useful
`to applications
`above
`received an NFS3ERRNOTSUP error from
`UNIX client
`that
`server would do the recovery necessary to either make it
`look
`had succeeded or return
`to the application like the link request
`is the burden of
`reasonable error
`the client
`In general
`it
`to recover
`
`stateless server
`assumes
`The NFS version
`protocol
`Statelessness means that
`the server does not
`implementation
`its clients in order
`need to maintain state about any of
`to
`function correctly Stateless servers have
`distinct advantage
`crash With stateless
`over stateful
`servers in the event of
`client need only retry
`request until
`servers
`the server
`the client
`does not even need to know that
`responds
`the server
`has crashed
`See additional
`comments
`cache
`in Duplicate request
`on page 99
`
`it holds nonvolatile state data
`to be useful
`server
`For
`stored in the file system Design assumptions in the NFS version
`regarding flushing of modified data to stable storage
`protocol
`reduce
`the number of
`failure modes in which data loss can occur
`In this way NFS version
`implementations can tolerate
`protocol
`the network
`failures including transient
`transient
`failures of
`In general server
`the NFS version
`implementations of
`protocol
`cannot
`tolerate
`non-transient
`failure of
`the stable storage
`itself
`However
`there exist
`fault
`tolerant
`implementations
`which attempt
`to address such problems
`
`protocol server cant
`to say that an NFS version
`is not
`That
`servers will maintain
`maintain noncritical
`state
`In many cases
`state cache
`about previous operations to increase performance
`For example
`client READ
`read-ahead of
`request might
`trigger
`the file into the servers data cache
`the next block of
`in the
`anticipation that
`the client
`read and the
`is doing
`sequential
`be satisfied from the servers
`next client READ
`request will
`data cache
`instead of
`from the disk
`Read-ahead on the server
`increases performance by overlapping server disk I/O with client
`the read-ahead block
`requests The important point here is that
`is not necessary for correct server behavior
`the server
`If
`read buffers recovery
`crashes and loses its memory cache of
`clients will continue
`simple on reboot
`read operations
`retrieving data from the server disk
`
`is
`
`Callaghan
`
`el al
`
`Informational
`
`Petitioner IBM – Ex. 1042, p. 9
`
`

`
`RFC 1813
`
`NFS Version
`
`Protocol
`
`June 1995
`
`Most data-modifying operations in the NFS protocol are
`is when
`That
`data modifying procedure returns
`synchronous
`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
`client WRITE
`synchronous
`to update data blocks
`request may cause the server
`file system
`information blocks
`and file attribute information
`the latter
`information is usually referred to as metadata When
`the WRITE
`the write data
`operation completes the client can assume that
`is safe and discard it
`This is
`the
`very important part of
`the server
`the server did not
`stateless nature of
`flush
`If
`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
`LINK and COMMIT
`MKDIR
`SYMLINK
`MKNOD
`REMOVE RMDIR RENAME
`
`introduces safe asynchronous writes
`The NFS version
`protocol
`on the server when the WRITE procedure is used in conjunction
`with the COMMIT procedure The COMMIT procedure provides
`way
`for the client
`asynchronous WRITE
`to flush data from previous
`on the server to stable storage and to detect whether
`requests
`the data See the procedure
`is necessary to retransmit
`it
`49 and COMMIT on page 92
`descriptions of WRITE on page
`
`The LOOKUP procedure is used by the client
`to traverse
`file names pathnames
`Each call
`to LOOKUP is
`multicomponent
`pathname There are two reasons
`used to resolve one segment of
`for restricting LOOKUP to
`is hard to
`single segment
`it
`standardize
`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
`the clients file system attachment points In
`must know about
`NFS version
`is the client
`that
`protocol
`implementations
`it
`constructs the hierarchical
`file name
`space using mounts to
`hierarchy Support utilities
`such as the Automounter
`build
`shared consistent
`the file
`provide
`way to manage
`image of
`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
`to implement
`protocol was
`cache consistency mechanism It
`time-based client-server
`NFS version
`implementations will
`expected
`use
`protocol
`similar mechanism The NFS version
`has
`some explicit
`protocol
`support
`in the form of additional attribute information to
`eliminate explicit attribute checks However
`caching
`is not
`
`is
`
`Callaghan el al
`
`Informational
`
`10
`
`Petitioner IBM – Ex. 1042, p. 10
`
`

`
`FEC 1813
`
`NFS Version
`
`Protocol
`
`June 1995
`
`is any caching policy defined by the protocol
`required nor
`the NFS version
`Neither
`the NFS version
`protocol nor
`means of maintaining strict client-server
`protocol provide
`and by implication consistency
`across client
`consistency
`caches
`
`Changes
`
`from the NES Version
`
`Protocol
`
`The ROOT and WRITECACHE procedures have been removed
`MKNOD
`procedure has been defined to allow the creation of special
`files eliminating the overloading of CREATE Caching
`on the
`client
`is not defined nor dictated by the NFS version
`protocol
`but additional
`information and hints have
`been added
`to the protocol
`to allow clients that
`implement caching to
`manage their caches more effectively
`Procedures that affect
`attributes of
`file or directory may now return the new
`attributes after the operation has completed to optimize out
`GETATTR used in validating attribute caches
`subsequent
`In
`addition operations that modify the directory in which the
`resides return the old and new attributes of
`the
`target object
`directory to allow clients to implement more intelligent
`cache
`invalidation procedures
`The ACCESS procedure provides access
`on the server
`the FSSTAT procedure returns
`permission checking
`information about
`file system the ESINFO procedure
`dynamic
`returns static information about
`the
`file system and server
`READDIRPLUS
`procedure returns file handles and attributes in
`addition to directory entries and the PATHCONF procedure
`file
`information about
`returns POSIX pathconf
`
`the
`
`Below is
`protocol
`
`the important changes between the NFS version
`list of
`protocol
`and the NES version
`
`File handle size
`The
`file handle has been increased to
`variable-length
`64 bytes maximum from
`fixed array of 32
`array of
`bytes This addresses some known requirements for
`file handle size The file handle was
`slightly larger
`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
`data transfer used in the READ
`The maximum size of
`in the FSINFO
`and WRITE procedures is now set by values
`return structure In addition preferred transfer sizes
`are returned by FSINFO The protocol does not place any
`limits on the maximum transfer sizes
`artificial
`
`Callaghan el al
`
`Informational
`
`11
`
`Petitioner IBM – Ex. 1042, p. 11
`
`

`
`RET
`
`1813
`
`NFS Version
`
`Protocol
`
`June 1995
`
`Filenames and pathnames are now specified as strings of
`variable length The actual
`length restrictions are
`determined by the client and server
`implementations as
`appropriate
`The protocol
`does not place any
`limits on the length The error
`artificial
`NFS3ERRNAMETOOLONG
`is provided to allow the server to
`return an indication to the client
`that
`received
`it
`to handle
`pathname that was too long for it
`
`Error return
`now return data for
`Error returns in some instances
`example attributes
`nfsstat3 now defines the full
`server No other
`of errors that
`can be returned by
`values are allowed
`
`set
`
`File type
`file type now includes NF3CHR and NF3BLK for
`The
`files Attributes for these types include
`special
`subfields 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
`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
`integers from four-byte integers Major and minor
`device information is now presented in
`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
`protocol
`the settable attributes
`In the NFS version
`the file attributes
`subset of
`were represented
`by
`structure 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
`discriminated
`that
`union for each
`field to tell whether or how to set
`field The atime and mtime fields can be set
`to either
`the servers current
`time or
`time supplied by the
`client
`
`LOOKUP
`
`The
`for
`
`LOOKUP return structure now includes the attributes
`the directory searched
`
`Callaghan el al
`
`Informational
`
`12
`
`Petitioner IBM – Ex. 1042, p. 12
`
`

`
`REC
`
`1813
`
`NFS Version
`
`Protocol
`
`June 1995
`
`ACCESS
`
`READ
`
`WRITE
`
`CREATE
`
`MKNOD
`
`An ACCESS procedure has been added
`to allow an explicit
`over-the-wire permissions check This addresses known
`ID mapping feature in many
`problems with the superuser
`implementations where due to mapping of root
`server
`user unexpected permission denied errors could occur
`file
`while reading from or writing to
`This also
`removes the assumption which was made in the NES
`version
`that access
`to files was based
`protocol
`solely on UNIX style mode bits
`
`reply structure includes
`is TRUE
`Boolean that
`The
`if
`the end-of-file was encountered during the READ
`This
`to correctly detect end-of-file
`allows the client
`
`The beginoffset
`fields were removed from
`and totalcount
`count
`The reply now includes
`the WRITE arguments
`so
`that
`the server can write less than the requested
`amount of data if
`required An indicator was added
`to
`to instruct
`the server as to the level of
`the arguments
`is required by the client
`cache synchronization that
`
`An exclusive flag and
`create verifier was added
`the exclusive creation of regular files
`
`for
`
`the creation of
`This procedure was added to support
`files This avoids overloading fields of CREATE
`special
`as was done
`in some MRS version
`protocol
`implementations
`
`READDIR
`
`The READDIR arguments
`verifier to allow
`now include
`the server to validate the cookie The cookie is now
`instead of
`64 bit unsigned integer
`byte array
`the
`protocol
`which was used in the MRS version
`This
`interoperability problems
`will help to reduce
`
`READDIRPLUS
`This procedure was added to return file handles and
`attributes in an extended directory list
`
`PSINFO
`
`FSINFO was added
`to provide nonvolatile information
`file system The reply includes preferred and
`about
`
`Callaghan el al
`
`Informational
`
`13
`
`Petitioner IBM – Ex. 1042, p. 13
`
`

`
`REC
`
`1813
`
`NFS Version
`
`Protocol
`
`June 1995
`
`maximum read transfer size preferred and maximum write
`transfer size and flags stating whether
`links or
`links are supported
`Also returned are
`symbolic
`preferred transfer size for READDIR procedure replies
`time granularity and whether
`server
`times can be set
`SETATTR request
`in
`
`PSSTAT was added
`to provide volatile information about
`such as the Unix
`file system for use by utilities
`system df command
`The
`reply includes the total size
`in the file system specified in bytes
`and free space
`the total number of
`files and number of
`free file slots
`in the file system and an estimate of
`time between
`for use in cache
`file system modifications
`consistency
`checking algorithms
`
`The COMMIT procedure provides the synchronization
`mechanism to be used with asynchronous WRITE
`operations
`
`PS TAT
`
`COMMIT
`
`RPC Information
`
`21 Authentication
`
`in the NULL procedure AUTH UNIX
`NONE
`The NPS service uses AUTH
`AUTH DES or AUTH KERB are used for all other procedures Other
`types may be supported in the future
`authentication
`
`22 Constants
`
`needed to call
`These are the RPC constants
`service
`They are given in decimal
`
`the NPS Version
`
`PROGRAM
`VERSION
`
`100003
`
`Transport
`
`address
`
`the TCP and UDP
`is normally supported over
`The NFS protocol
`protocols
`It uses port 2049 the same as the NES version
`protocol
`
`24 Sizes
`
`These are the sizes given in decimal bytes of various XDR
`protocol
`structures
`used in the NFS version
`
`Callaghan el al
`
`Informational
`
`14
`
`Petitioner IBM – Ex. 1042, p. 14
`
`

`
`REC
`
`1813
`
`NFS Version
`
`Protocol
`
`June 1995
`
`NFS3FHSIZE 64
`The maximum size in bytes of
`
`the opaque
`
`file handle
`
`NFS3COOKIEVERFSIZE
`the opaque
`The size in bytes of
`and READDIRPLUS
`READDIR
`
`cookie verifier passed by
`
`NPS3CREATEVERFSIZE
`The size in bytes of
`exclusive CREATE
`
`NFS3WRITEVERFSIZE
`The size in bytes of
`asynchronous WRITE
`
`25 Basic Data Types
`
`the opaque verifier used for
`
`the opaque verifier used for
`
`The following XDR definitions are basic definitions that are
`used in other structures
`
`nt 64
`
`int64
`
`uint32
`
`int32
`
`typedef unsigned hyper uint64
`
`typedef hyper
`
`int64
`
`typedef unsigned long uint32
`
`typedef
`
`long int32
`
`filename3
`typedef string filename3
`
`nfspath3
`typedef string nfspath3
`
`file d3
`typedef uint64 fileid3
`
`cookie3
`
`typedef uint64 cookie3
`
`cookieverf
`typedef
`
`opaque
`
`cookieverf3
`
`COOKIEVERESIZE
`
`Callaghan el al
`
`Informational
`
`15
`
`Petitioner IBM – Ex. 1042, p. 15
`
`

`
`REC
`
`1813
`
`NFS Version
`
`Protocol
`
`June 1995
`
`createverf3
`typedef
`
`writeverf3
`typedef
`
`opaque createverf3
`
`CREATEVERFSIZEJ
`
`opaque writeverf3
`
`WRITEVERFSIZE
`
`typedef uint32 uid3
`
`typedef uint32 gid3
`
`d3
`
`d3
`
`size3
`
`typedef uint64 size3
`
`off set3
`typedef uint64 offset3
`
`mode3
`
`count3
`
`typedef uint32 mode3
`
`typedef uint32 count3
`
`nf sstat3
`enum nfsstat3
`NFS3OK
`NPS3ERRPERM
`NFS3ERRNOENT
`NFS3ERRIO
`NFS3ERRNXIO
`NFS3ERRACCES
`NPS3ERR EXIST
`NFS3ERRXDEV
`NFS3ERRNODEV
`NPS3ERRNOTDIR
`NFS3ERRISDIR
`NFS3ERRINVAL
`NFS3ERR PRIG
`NFS3ERRNOSPC
`NPS3ERRROFS
`NFS3ERRMLINK
`NFS3ERRNAMETOOLONG
`NPS3ERRNOTEMPTY
`NFS3ERRDQUOT
`NFS3ERR STALE
`NFS3ERR REMOTE
`NFS3ERRBADHANDLE
`
`13
`17
`18
`19
`20
`21
`22
`27
`28
`30
`31
`63
`66
`69
`70
`71
`10001
`
`Callaghan el al
`
`Informational
`
`16J
`
`Petitioner IBM – Ex. 1042, p. 16
`
`

`
`REC
`
`1813
`
`NFS Version
`
`Protocol
`
`June 1995
`
`NFS3ERR NOT SYNC
`NFS3ERR BAD COOKIE
`NFS3ERRNOTSUPP
`NFS3ERRTOOSMALL
`NFS3ERRSERVERFAULT
`NFS3ERRBADTYPE
`NFS3ERRJIJKEBOX
`
`10002
`10003
`10004
`10005
`10006
`10007
`10008
`
`The nfsstat3 type is returned with every procedures results
`for the NULL procedure
`value of NFS3 OK indicates that
`except
`the call completed successfully Any other value indicates that
`some error occurred on the call as identified by the error
`code Note that
`followed
`the precise numeric encoding must be
`server Servers are
`No other values may be returned by
`to make
`best effort mapping of error conditions to
`expected
`the set of error codes defined In addition no error
`are specified by this specification Error
`precedences
`returned
`determine the error value that should be
`precedences
`given situation The error
`when more than one error applies in
`precedence will
`be determined by the individual server
`the client
`requires specific error
`If
`implementation
`precedences
`for the specific errors for
`should check
`it
`itself
`
`2.6 Defined Error Numbers
`
`description of each defined error follows
`
`NFS3OK
`Indicates the call completed successfully
`
`NFS3 ERR PERM
`Not owner
`The operation was not allowed because the
`privileged user root or not
`caller is either not
`the operation
`owner of
`the target of
`
`the
`
`NFS3 ERR NOENT
`No such file or directory The file or directory name
`specified does not exist
`
`NFS3 ERR_ID
`disk error
`hard error for example
`I/O error
`the requested operation
`occurred while processing
`
`NFS3 ERR NXIO
`I/O error No such device or address
`
`Callaghan el al
`
`Informational
`
`17
`
`Petitioner IBM – Ex. 1042, p. 17
`
`

`
`RFC 1813
`
`NFS version
`
`Protocol
`
`June 1995
`
`NFS3ERR_ACCES
`Permission denied The caller does not have the correct
`permission to perform the requested operation Contrast
`which restricts itself
`to owner
`this with NFS3ERR_PERM
`or privileged user permission failures
`
`NFS3 ERR_EXIST
`File exists The file specified already exists
`
`NFS3ERR_XDEV
`Attempt
`
`to do
`
`cross-device hard link
`
`NFS3ERR_NODEv
`No such device
`
`NFS3ERR_NOTDIR
`directory The caller specified
`Not
`directory operation
`
`non-directory in
`
`NFS3ERR_ISDIR
`directory The caller specified
`Is
`non-directory operation
`
`directory in
`
`NFS3ERR_INVAL
`Invalid argument or unsupported argument for an
`READLINK on an
`operation Two examples are attempting
`object other
`symbolic link or attempting to
`than
`SETATTR
`time field on
`server that does not support
`this operation
`
`NFS3ERR_FBIG
`File too large The operation would have caused
`grow beyond the ser