Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next  

RFC 3010

NFS version 4 Protocol

Pages: 212
Group: DHC

Obsoleted by:  3530
Part 2 of 8 – Pages 23 to 50
First   Prev   Next

ToP   noToC   RFC3010 - Page 23   prevText
4.  Filehandles

   The filehandle in the NFS protocol is a per server unique identifier
   for a file system object.  The contents of the filehandle are opaque
   to the client.  Therefore, the server is responsible for translating
   the filehandle to an internal representation of the file system
   object.  Since the filehandle is the client's reference to an object
   and the client may cache this reference, the server SHOULD not reuse
   a filehandle for another file system object.  If the server needs to
   reuse a filehandle value, the time elapsed before reuse SHOULD be
   large enough such that it is unlikely the client has a cached copy of
   the reused filehandle value.  Note that a client may cache a
   filehandle for a very long time.  For example, a client may cache NFS
   data to local storage as a method to expand its effective cache size
   and as a means to survive client restarts.  Therefore, the lifetime
   of a cached filehandle may be extended.
ToP   noToC   RFC3010 - Page 24
4.1.  Obtaining the First Filehandle

   The operations of the NFS protocol are defined in terms of one or
   more filehandles.  Therefore, the client needs a filehandle to
   initiate communication with the server.  With the NFS version 2
   protocol [RFC1094] and the NFS version 3 protocol [RFC1813], there
   exists an ancillary protocol to obtain this first filehandle.  The
   MOUNT protocol, RPC program number 100005, provides the mechanism of
   translating a string based file system path name to a filehandle
   which can then be used by the NFS protocols.

   The MOUNT protocol has deficiencies in the area of security and use
   via firewalls.  This is one reason that the use of the public
   filehandle was introduced in [RFC2054] and [RFC2055].  With the use
   of the public filehandle in combination with the LOOKUP procedure in
   the NFS version 2 and 3 protocols, it has been demonstrated that the
   MOUNT protocol is unnecessary for viable interaction between NFS
   client and server.

   Therefore, the NFS version 4 protocol will not use an ancillary
   protocol for translation from string based path names to a
   filehandle.  Two special filehandles will be used as starting points
   for the NFS client.

4.1.1.  Root Filehandle

   The first of the special filehandles is the ROOT filehandle.  The
   ROOT filehandle is the "conceptual" root of the file system name
   space at the NFS server.  The client uses or starts with the ROOT
   filehandle by employing the PUTROOTFH operation.  The PUTROOTFH
   operation instructs the server to set the "current" filehandle to the
   ROOT of the server's file tree.  Once this PUTROOTFH operation is
   used, the client can then traverse the entirety of the server's file
   tree with the LOOKUP procedure.  A complete discussion of the server
   name space is in the section "NFS Server Name Space".

4.1.2.  Public Filehandle

   The second special filehandle is the PUBLIC filehandle.  Unlike the
   ROOT filehandle, the PUBLIC filehandle may be bound or represent an
   arbitrary file system object at the server.  The server is
   responsible for this binding.  It may be that the PUBLIC filehandle
   and the ROOT filehandle refer to the same file system object.
   However, it is up to the administrative software at the server and
   the policies of the server administrator to define the binding of the
   PUBLIC filehandle and server file system object.  The client may not
   make any assumptions about this binding.
ToP   noToC   RFC3010 - Page 25
4.2.  Filehandle Types

   In the NFS version 2 and 3 protocols, there was one type of
   filehandle with a single set of semantics.  The NFS version 4
   protocol introduces a new type of filehandle in an attempt to
   accommodate certain server environments.  The first type of
   filehandle is 'persistent'.  The semantics of a persistent filehandle
   are the same as the filehandles of the NFS version 2 and 3 protocols.
   The second or new type of filehandle is the "volatile" filehandle.

   The volatile filehandle type is being introduced to address server
   functionality or implementation issues which make correct
   implementation of a persistent filehandle infeasible.  Some server
   environments do not provide a file system level invariant that can be
   used to construct a persistent filehandle.  The underlying server
   file system may not provide the invariant or the server's file system
   programming interfaces may not provide access to the needed
   invariant.  Volatile filehandles may ease the implementation of
   server functionality such as hierarchical storage management or file
   system reorganization or migration.  However, the volatile filehandle
   increases the implementation burden for the client.  However this
   increased burden is deemed acceptable based on the overall gains
   achieved by the protocol.

   Since the client will need to handle persistent and volatile
   filehandle differently, a file attribute is defined which may be used
   by the client to determine the filehandle types being returned by the

4.2.1.  General Properties of a Filehandle

   The filehandle contains all the information the server needs to
   distinguish an individual file.  To the client, the filehandle is
   opaque. The client stores filehandles for use in a later request and
   can compare two filehandles from the same server for equality by
   doing a byte-by-byte comparison.  However, the client MUST NOT
   otherwise interpret the contents of filehandles.  If two filehandles
   from the same server are equal, they MUST refer to the same file.  If
   they are not equal, the client may use information provided by the
   server, in the form of file attributes, to determine whether they
   denote the same files or different files.  The client would do this
   as necessary for client side caching.  Servers SHOULD try to maintain
   a one-to-one correspondence between filehandles and files but this is
   not required.  Clients MUST use filehandle comparisons only to
   improve performance, not for correct behavior.  All clients need to
   be prepared for situations in which it cannot be determined whether
   two filehandles denote the same object and in such cases, avoid
   making invalid assumptions which might cause incorrect behavior.
ToP   noToC   RFC3010 - Page 26
   Further discussion of filehandle and attribute comparison in the
   context of data caching is presented in the section "Data Caching and
   File Identity".

   As an example, in the case that two different path names when
   traversed at the server terminate at the same file system object, the
   server SHOULD return the same filehandle for each path.  This can
   occur if a hard link is used to create two file names which refer to
   the same underlying file object and associated data.  For example, if
   paths /a/b/c and /a/d/c refer to the same file, the server SHOULD
   return the same filehandle for both path names traversals.

4.2.2.  Persistent Filehandle

   A persistent filehandle is defined as having a fixed value for the
   lifetime of the file system object to which it refers.  Once the
   server creates the filehandle for a file system object, the server
   MUST accept the same filehandle for the object for the lifetime of
   the object.  If the server restarts or reboots the NFS server must
   honor the same filehandle value as it did in the server's previous
   instantiation.  Similarly, if the file system is migrated, the new
   NFS server must honor the same file handle as the old NFS server.

   The persistent filehandle will be become stale or invalid when the
   file system object is removed.  When the server is presented with a
   persistent filehandle that refers to a deleted object, it MUST return
   an error of NFS4ERR_STALE.  A filehandle may become stale when the
   file system containing the object is no longer available.  The file
   system may become unavailable if it exists on removable media and the
   media is no longer available at the server or the file system in
   whole has been destroyed or the file system has simply been removed
   from the server's name space (i.e. unmounted in a Unix environment).

4.2.3.  Volatile Filehandle

   A volatile filehandle does not share the same longevity
   characteristics of a persistent filehandle.  The server may determine
   that a volatile filehandle is no longer valid at many different
   points in time.  If the server can definitively determine that a
   volatile filehandle refers to an object that has been removed, the
   server should return NFS4ERR_STALE to the client (as is the case for
   persistent filehandles).  In all other cases where the server
   determines that a volatile filehandle can no longer be used, it
   should return an error of NFS4ERR_FHEXPIRED.
ToP   noToC   RFC3010 - Page 27
   The mandatory attribute "fh_expire_type" is used by the client to
   determine what type of filehandle the server is providing for a
   particular file system.  This attribute is a bitmask with the
   following values:

         The value of FH4_PERSISTENT is used to indicate a persistent
         filehandle, which is valid until the object is removed from the
         file system.  The server will not return NFS4ERR_FHEXPIRED for
         this filehandle.  FH4_PERSISTENT is defined as a value in which
         none of the bits specified below are set.

         The filehandle will not expire while client has the file open.
         If this bit is set, then the values FH4_VOLATILE_ANY or
         FH4_VOL_RENAME do not impact expiration while the file is open.
         Once the file is closed or if the FH4_NOEXPIRE_WITH_OPEN bit is
         false, the rest of the volatile related bits apply.

         The filehandle may expire at any time and will expire during
         system migration and rename.

         The filehandle will expire during file system migration.  May
         only be set if FH4_VOLATILE_ANY is not set.

         The filehandle may expire due to a rename.  This includes a
         rename by the requesting client or a rename by another client.
         May only be set if FH4_VOLATILE_ANY is not set.

   Servers which provide volatile filehandles should deny a RENAME or
   REMOVE that would affect an OPEN file or any of the components
   leading to the OPEN file.  In addition, the server should deny all
   RENAME or REMOVE requests during the grace or lease period upon
   server restart.

   The reader may be wondering why there are three FH4_VOL* bits and why
   FH4_VOLATILE_ANY is exclusive of FH4_VOL_MIGRATION and
   FH4_VOL_RENAME.  If the a filehandle is normally persistent but
   cannot persist across a file set migration, then the presence of the
   FH4_VOL_MIGRATION or FH4_VOL_RENAME tells the client that it can
   treat the file handle as persistent for purposes of maintaining a
   file name to file handle cache, except for the specific event
   described by the bit.  However, FH4_VOLATILE_ANY tells the client
   that it should not maintain such a cache for unopened files.  A
   server MUST not present FH4_VOLATILE_ANY with FH4_VOL_MIGRATION or
ToP   noToC   RFC3010 - Page 28
   FH4_VOL_RENAME as this will lead to confusion.  FH4_VOLATILE_ANY
   implies that the file handle will expire upon migration or rename, in
   addition to other events.

4.2.4.  One Method of Constructing a Volatile Filehandle

   As mentioned, in some instances a filehandle is stale (no longer
   valid; perhaps because the file was removed from the server) or it is
   expired (the underlying file is valid but since the filehandle is
   volatile, it may have expired).  Thus the server needs to be able to
   return NFS4ERR_STALE in the former case and NFS4ERR_FHEXPIRED in the
   latter case. This can be done by careful construction of the volatile
   filehandle.  One possible implementation follows.

   A volatile filehandle, while opaque to the client could contain:

   [volatile bit = 1 | server boot time | slot | generation number]

   o  slot is an index in the server volatile filehandle table

   o  generation number is the generation number for the table

   If the server boot time is less than the current server boot time,
   return NFS4ERR_FHEXPIRED.  If slot is out of range, return
   NFS4ERR_BADHANDLE.  If the generation number does not match, return

   When the server reboots, the table is gone (it is volatile).

   If volatile bit is 0, then it is a persistent filehandle with a
   different structure following it.

4.3.  Client Recovery from Filehandle Expiration

   If possible, the client SHOULD recover from the receipt of an
   NFS4ERR_FHEXPIRED error.  The client must take on additional
   responsibility so that it may prepare itself to recover from the
   expiration of a volatile filehandle.  If the server returns
   persistent filehandles, the client does not need these additional

   For volatile filehandles, most commonly the client will need to store
   the component names leading up to and including the file system
   object in question.  With these names, the client should be able to
   recover by finding a filehandle in the name space that is still
   available or by starting at the root of the server's file system name
ToP   noToC   RFC3010 - Page 29
   If the expired filehandle refers to an object that has been removed
   from the file system, obviously the client will not be able to
   recover from the expired filehandle.

   It is also possible that the expired filehandle refers to a file that
   has been renamed.  If the file was renamed by another client, again
   it is possible that the original client will not be able to recover.
   However, in the case that the client itself is renaming the file and
   the file is open, it is possible that the client may be able to
   recover.  The client can determine the new path name based on the
   processing of the rename request.  The client can then regenerate the
   new filehandle based on the new path name.  The client could also use
   the compound operation mechanism to construct a set of operations

            RENAME A B
            LOOKUP B

5.  File Attributes

   To meet the requirements of extensibility and increased
   interoperability with non-Unix platforms, attributes must be handled
   in a flexible manner.  The NFS Version 3 fattr3 structure contains a
   fixed list of attributes that not all clients and servers are able to
   support or care about.  The fattr3 structure can not be extended as
   new needs arise and it provides no way to indicate non-support.  With
   the NFS Version 4 protocol, the client will be able to ask what
   attributes the server supports and will be able to request only those
   attributes in which it is interested.

   To this end, attributes will be divided into three groups: mandatory,
   recommended, and named.  Both mandatory and recommended attributes
   are supported in the NFS version 4 protocol by a specific and well-
   defined encoding and are identified by number.  They are requested by
   setting a bit in the bit vector sent in the GETATTR request; the
   server response includes a bit vector to list what attributes were
   returned in the response.  New mandatory or recommended attributes
   may be added to the NFS protocol between major revisions by
   publishing a standards-track RFC which allocates a new attribute
   number value and defines the encoding for the attribute.  See the
   section "Minor Versioning" for further discussion.

   Named attributes are accessed by the new OPENATTR operation, which
   accesses a hidden directory of attributes associated with a file
   system object.  OPENATTR takes a filehandle for the object and
   returns the filehandle for the attribute hierarchy.  The filehandle
   for the named attributes is a directory object accessible by LOOKUP
ToP   noToC   RFC3010 - Page 30
   or READDIR and contains files whose names represent the named
   attributes and whose data bytes are the value of the attribute.  For

         LOOKUP     "foo"       ; look up file
         GETATTR    attrbits
         OPENATTR               ; access foo's named attributes
         LOOKUP     "x11icon"   ; look up specific attribute
         READ       0,4096      ; read stream of bytes

   Named attributes are intended for data needed by applications rather
   than by an NFS client implementation.  NFS implementors are strongly
   encouraged to define their new attributes as recommended attributes
   by bringing them to the IETF standards-track process.

   The set of attributes which are classified as mandatory is
   deliberately small since servers must do whatever it takes to support
   them.  The recommended attributes may be unsupported; though a server
   should support as many as it can.  Attributes are deemed mandatory if
   the data is both needed by a large number of clients and is not
   otherwise reasonably computable by the client when support is not
   provided on the server.

5.1.  Mandatory Attributes

   These MUST be supported by every NFS Version 4 client and server in
   order to ensure a minimum level of interoperability.  The server must
   store and return these attributes and the client must be able to
   function with an attribute set limited to these attributes.  With
   just the mandatory attributes some client functionality may be
   impaired or limited in some ways.  A client may ask for any of these
   attributes to be returned by setting a bit in the GETATTR request and
   the server must return their value.

5.2.  Recommended Attributes

   These attributes are understood well enough to warrant support in the
   NFS Version 4 protocol.  However, they may not be supported on all
   clients and servers.  A client may ask for any of these attributes to
   be returned by setting a bit in the GETATTR request but must handle
   the case where the server does not return them.  A client may ask for
   the set of attributes the server supports and should not request
   attributes the server does not support.  A server should be tolerant
   of requests for unsupported attributes and simply not return them
   rather than considering the request an error.  It is expected that
   servers will support all attributes they comfortably can and only
   fail to support attributes which are difficult to support in their
   operating environments.  A server should provide attributes whenever
ToP   noToC   RFC3010 - Page 31
   they don't have to "tell lies" to the client.  For example, a file
   modification time should be either an accurate time or should not be
   supported by the server.  This will not always be comfortable to
   clients but it seems that the client has a better ability to
   fabricate or construct an attribute or do without the attribute.

5.3.  Named Attributes

   These attributes are not supported by direct encoding in the NFS
   Version 4 protocol but are accessed by string names rather than
   numbers and correspond to an uninterpreted stream of bytes which are
   stored with the file system object.  The name space for these
   attributes may be accessed by using the OPENATTR operation.  The
   OPENATTR operation returns a filehandle for a virtual "attribute
   directory" and further perusal of the name space may be done using
   READDIR and LOOKUP operations on this filehandle.  Named attributes
   may then be examined or changed by normal READ and WRITE and CREATE
   operations on the filehandles returned from READDIR and LOOKUP.
   Named attributes may have attributes.

   It is recommended that servers support arbitrary named attributes.  A
   client should not depend on the ability to store any named attributes
   in the server's file system.  If a server does support named
   attributes, a client which is also able to handle them should be able
   to copy a file's data and meta-data with complete transparency from
   one location to another; this would imply that names allowed for
   regular directory entries are valid for named attribute names as

   Names of attributes will not be controlled by this document or other
   IETF standards track documents.  See the section "IANA
   Considerations" for further discussion.

5.4.  Mandatory Attributes - Definitions

   Name              #    DataType     Access   Description
   supp_attr         0    bitmap       READ     The bit vector which
                                                would retrieve all
                                                mandatory and
                                                recommended attributes
                                                that are supported for
                                                this object.

   type              1    nfs4_ftype   READ     The type of the object
                                                (file, directory,
ToP   noToC   RFC3010 - Page 32
   fh_expire_type    2    uint32       READ     Server uses this to
                                                specify filehandle
                                                expiration behavior to
                                                the client.  See the
                                                section "Filehandles"
                                                for additional

   change            3    uint64       READ     A value created by the
                                                server that the client
                                                can use to determine
                                                if file data,
                                                directory contents or
                                                attributes of the
                                                object have been
                                                modified.  The server
                                                may return the
                                                object's time_modify
                                                attribute for this
                                                attribute's value but
                                                only if the file
                                                system object can not
                                                be updated more
                                                frequently than the
                                                resolution of

   size              4    uint64       R/W      The size of the object
                                                in bytes.

   link_support      5    boolean      READ     Does the object's file
                                                system supports hard

   symlink_support   6    boolean      READ     Does the object's file
                                                system supports
                                                symbolic links?

   named_attr        7    boolean      READ     Does this object have
                                                named attributes?

   fsid              8    fsid4        READ     Unique file system
                                                identifier for the
                                                file system holding
                                                this object.  fsid
                                                contains major and
                                                minor components each
                                                of which are uint64.
ToP   noToC   RFC3010 - Page 33
   unique_handles    9    boolean      READ     Are two distinct
                                                filehandles guaranteed
                                                to refer to two
                                                different file system

   lease_time        10   nfs_lease4   READ     Duration of leases at
                                                server in seconds.

   rdattr_error      11   enum         READ     Error returned from
                                                getattr during

5.5.  Recommended Attributes - Definitions

   Name               #    Data Type      Access   Description
   ACL                12   nfsace4<>      R/W      The access control
                                                   list for the object.

   aclsupport         13   uint32         READ     Indicates what types
                                                   of ACLs are supported
                                                   on the current file

   archive            14   boolean        R/W      Whether or not this
                                                   file has been
                                                   archived since the
                                                   time of last
                                                   (deprecated in favor
                                                   of time_backup).

   cansettime         15   boolean        READ     Is the server able to
                                                   change the times for
                                                   a file system object
                                                   as specified in a
                                                   SETATTR operation?

   case_insensitive   16   boolean        READ     Are filename
                                                   comparisons on this
                                                   file system case

   case_preserving    17   boolean        READ     Is filename case on
                                                   this file system
ToP   noToC   RFC3010 - Page 34
   chown_restricted   18   boolean        READ     If TRUE, the server
                                                   will reject any
                                                   request to change
                                                   either the owner or
                                                   the group associated
                                                   with a file if the
                                                   caller is not a
                                                   privileged user (for
                                                   example, "root" in
                                                   Unix operating
                                                   environments or in NT
                                                   the "Take Ownership"

   filehandle         19   nfs4_fh        READ     The filehandle of
                                                   this object
                                                   (primarily for
                                                   readdir requests).

   fileid             20   uint64         READ     A number uniquely
                                                   identifying the file
                                                   within the file

   files_avail        21   uint64         READ     File slots available
                                                   to this user on the
                                                   file system
                                                   containing this
                                                   object - this should
                                                   be the smallest
                                                   relevant limit.

   files_free         22   uint64         READ     Free file slots on
                                                   the file system
                                                   containing this
                                                   object - this should
                                                   be the smallest
                                                   relevant limit.

   files_total        23   uint64         READ     Total file slots on
                                                   the file system
                                                   containing this
ToP   noToC   RFC3010 - Page 35
   fs_locations       24   fs_locations   READ     Locations where this
                                                   file system may be
                                                   found.  If the server
                                                   returns NFS4ERR_MOVED
                                                   as an error, this
                                                   attribute must be

   hidden             25   boolean        R/W      Is file considered
                                                   hidden with respect
                                                   to the WIN32 API?

   homogeneous        26   boolean        READ     Whether or not this
                                                   object's file system
                                                   is homogeneous, i.e.
                                                   are per file system
                                                   attributes the same
                                                   for all file system's

   maxfilesize        27   uint64         READ     Maximum supported
                                                   file size for the
                                                   file system of this

   maxlink            28   uint32         READ     Maximum number of
                                                   links for this

   maxname            29   uint32         READ     Maximum filename size
                                                   supported for this

   maxread            30   uint64         READ     Maximum read size
                                                   supported for this

   maxwrite           31   uint64         READ     Maximum write size
                                                   supported for this
                                                   object.  This
                                                   attribute SHOULD be
                                                   supported if the file
                                                   is writable.  Lack of
                                                   this attribute can
                                                   lead to the client
                                                   either wasting
ToP   noToC   RFC3010 - Page 36
                                                   bandwidth or not
                                                   receiving the best

   mimetype           32   utf8<>         R/W      MIME body
                                                   type/subtype of this

   mode               33   mode4          R/W      Unix-style permission
                                                   bits for this object
                                                   (deprecated in favor
                                                   of ACLs)

   no_trunc           34   boolean        READ     If a name longer than
                                                   name_max is used,
                                                   will an error be
                                                   returned or will the
                                                   name be truncated?

   numlinks           35   uint32         READ     Number of hard links
                                                   to this object.

   owner              36   utf8<>         R/W      The string name of
                                                   the owner of this

   owner_group        37   utf8<>         R/W      The string name of
                                                   the group ownership
                                                   of this object.

   quota_avail_hard   38   uint64         READ     For definition see
                                                   "Quota Attributes"
                                                   section below.

   quota_avail_soft   39   uint64         READ     For definition see
                                                   "Quota Attributes"
                                                   section below.

   quota_used         40   uint64         READ     For definition see
                                                   "Quota Attributes"
                                                   section below.

   rawdev             41   specdata4      READ     Raw device
                                                   identifier.  Unix
                                                   device major/minor
                                                   node information.
ToP   noToC   RFC3010 - Page 37
   space_avail        42   uint64         READ     Disk space in bytes
                                                   available to this
                                                   user on the file
                                                   system containing
                                                   this object - this
                                                   should be the
                                                   smallest relevant

   space_free         43   uint64         READ     Free disk space in
                                                   bytes on the file
                                                   system containing
                                                   this object - this
                                                   should be the
                                                   smallest relevant

   space_total        44   uint64         READ     Total disk space in
                                                   bytes on the file
                                                   system containing
                                                   this object.

   space_used         45   uint64         READ     Number of file system
                                                   bytes allocated to
                                                   this object.

   system             46   boolean        R/W      Is this file a system
                                                   file with respect to
                                                   the WIN32 API?

   time_access        47   nfstime4       READ     The time of last
                                                   access to the object.

   time_access_set    48   settime4       WRITE    Set the time of last
                                                   access to the object.
                                                   SETATTR use only.

   time_backup        49   nfstime4       R/W      The time of last
                                                   backup of the object.

   time_create        50   nfstime4       R/W      The time of creation
                                                   of the object. This
                                                   attribute does not
                                                   have any relation to
                                                   the traditional Unix
                                                   file attribute
                                                   "ctime" or "change
ToP   noToC   RFC3010 - Page 38
   time_delta         51   nfstime4       READ     Smallest useful
                                                   server time

   time_metadata      52   nfstime4       R/W      The time of last
                                                   modification of the

   time_modify        53   nfstime4       READ     The time of last
                                                   modification to the

   time_modify_set    54   settime4       WRITE    Set the time of last
                                                   modification to the
                                                   object.  SETATTR use

5.6.  Interpreting owner and owner_group

   The recommended attributes "owner" and "owner_group" are represented
   in terms of a UTF-8 string.  To avoid a representation that is tied
   to a particular underlying implementation at the client or server,
   the use of the UTF-8 string has been chosen.  Note that section 6.1
   of [RFC2624] provides additional rationale.  It is expected that the
   client and server will have their own local representation of owner
   and owner_group that is used for local storage or presentation to the
   end user.  Therefore, it is expected that when these attributes are
   transferred between the client and server that the local
   representation is translated to a syntax of the form
   "user@dns_domain".  This will allow for a client and server that do
   not use the same local representation the ability to translate to a
   common syntax that can be interpreted by both.

   The translation is not specified as part of the protocol.  This
   allows various solutions to be employed.  For example, a local
   translation table may be consulted that maps between a numeric id to
   the user@dns_domain syntax.  A name service may also be used to
   accomplish the translation.  The "dns_domain" portion of the owner
   string is meant to be a DNS domain name.  For example,

   In the case where there is no translation available to the client or
   server, the attribute value must be constructed without the "@".
   Therefore, the absence of the @ from the owner or owner_group
   attribute signifies that no translation was available and the
   receiver of the attribute should not place any special meaning with
ToP   noToC   RFC3010 - Page 39
   the attribute value.  Even though the attribute value can not be
   translated, it may still be useful.  In the case of a client, the
   attribute string may be used for local display of ownership.

5.7.  Character Case Attributes

   With respect to the case_insensitive and case_preserving attributes,
   each UCS-4 character (which UTF-8 encodes) has a "long descriptive
   name" [RFC1345] which may or may not included the word "CAPITAL" or
   "SMALL".  The presence of SMALL or CAPITAL allows an NFS server to
   implement unambiguous and efficient table driven mappings for case
   insensitive comparisons, and non-case-preserving storage.  For
   general character handling and internationalization issues, see the
   section "Internationalization".

5.8.  Quota Attributes

   For the attributes related to file system quotas, the following
   definitions apply:

         The value in bytes which represents the amount of additional
         disk space that can be allocated to this file or directory
         before the user may reasonably be warned.  It is understood
         that this space may be consumed by allocations to other files
         or directories though there is a rule as to which other files
         or directories.

         The value in bytes which represent the amount of additional
         disk space beyond the current allocation that can be allocated
         to this file or directory before further allocations will be
         refused.  It is understood that this space may be consumed by
         allocations to other files or directories.

         The value in bytes which represent the amount of disc space
         used by this file or directory and possibly a number of other
         similar files or directories, where the set of "similar" meets
         at least the criterion that allocating space to any file or
         directory in the set will reduce the "quota_avail_hard" of
         every other file or directory in the set.

         Note that there may be a number of distinct but overlapping
         sets of files or directories for which a quota_used value is
         maintained. E.g. "all files with a given owner", "all files
         with a given group owner". etc.
ToP   noToC   RFC3010 - Page 40
         The server is at liberty to choose any of those sets but should
         do so in a repeatable way.  The rule may be configured per-
         filesystem or may be "choose the set with the smallest quota".

5.9.  Access Control Lists

   The NFS ACL attribute is an array of access control entries (ACE).
   There are various access control entry types.  The server is able to
   communicate which ACE types are supported by returning the
   appropriate value within the aclsupport attribute.  The types of ACEs
   are defined as follows:

   Type         Description
   ALLOW        Explicitly grants the access defined in
                acemask4 to the file or directory.

   DENY         Explicitly denies the access defined in
                acemask4 to the file or directory.

   AUDIT        LOG (system dependent) any access
                attempt to a file or directory which
                uses any of the access methods specified
                in acemask4.

   ALARM        Generate a system ALARM (system
                dependent) when any access attempt is
                made to a file or directory for the
                access methods specified in acemask4.

   The NFS ACE attribute is defined as follows:

   typedef uint32_t        acetype4;
   typedef uint32_t        aceflag4;
   typedef uint32_t        acemask4;

   struct nfsace4 {
           acetype4        type;
           aceflag4        flag;
           acemask4        access_mask;
           utf8string      who;

   To determine if an ACCESS or OPEN request succeeds each nfsace4 entry
   is processed in order by the server.  Only ACEs which have a "who"
   that matches the requester are considered.  Each ACE is processed
   until all of the bits of the requester's access have been ALLOWED.
   Once a bit (see below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it
ToP   noToC   RFC3010 - Page 41
   is no longer considered in the processing of later ACEs. If an
   ACCESS_DENIED_ACE is encountered where the requester's mode still has
   unALLOWED bits in common with the "access_mask" of the ACE, the
   request is denied.

   The bitmask constants used to represent the above definitions within
   the aclsupport attribute are as follows:

   const ACL4_SUPPORT_ALLOW_ACL    = 0x00000001;
   const ACL4_SUPPORT_DENY_ACL     = 0x00000002;
   const ACL4_SUPPORT_AUDIT_ACL    = 0x00000004;
   const ACL4_SUPPORT_ALARM_ACL    = 0x00000008;

5.9.1.  ACE type

   The semantics of the "type" field follow the descriptions provided

   The bitmask constants used for the type field are as follows:

   const ACE4_ACCESS_ALLOWED_ACE_TYPE      = 0x00000000;
   const ACE4_ACCESS_DENIED_ACE_TYPE       = 0x00000001;
   const ACE4_SYSTEM_AUDIT_ACE_TYPE        = 0x00000002;
   const ACE4_SYSTEM_ALARM_ACE_TYPE        = 0x00000003;

5.9.2.  ACE flag

   The "flag" field contains values based on the following descriptions.


   Can be placed on a directory and indicates that this ACE should be
   added to each new non-directory file created.


   Can be placed on a directory and indicates that this ACE should be
   added to each new directory created.


   Can be placed on a directory but does not apply to the directory,
   only to newly created files/directories as specified by the above two

ToP   noToC   RFC3010 - Page 42
   Can be placed on a directory. Normally when a new directory is
   created and an ACE exists on the parent directory which is marked
   ACL4_DIRECTORY_INHERIT_ACE, two ACEs are placed on the new directory.
   One for the directory itself and one which is an inheritable ACE for
   newly created directories.  This flag tells the server to not place
   an ACE on the newly created directory which is inheritable by
   subdirectories of the created directory.



   Both indicate for AUDIT and ALARM which state to log the event.  On
   every ACCESS or OPEN call which occurs on a file or directory which
   has an ACL that is of type ACE4_SYSTEM_AUDIT_ACE_TYPE or
   ACE4_SYSTEM_ALARM_ACE_TYPE, the attempted access is compared to the
   ace4mask of these ACLs. If the access is a subset of ace4mask and the
   identifier match, an AUDIT trail or an ALARM is generated.  By
   default this happens regardless of the success or failure of the
   ACCESS or OPEN call.

   The flag ACE4_SUCCESSFUL_ACCESS_ACE_FLAG only produces the AUDIT or
   ALARM if the ACCESS or OPEN call is successful. The
   or OPEN call fails.


   Indicates that the "who" refers to a GROUP as defined under Unix.

   The bitmask constants used for the flag field are as follows:

   const ACE4_FILE_INHERIT_ACE             = 0x00000001;
   const ACE4_DIRECTORY_INHERIT_ACE        = 0x00000002;
   const ACE4_NO_PROPAGATE_INHERIT_ACE     = 0x00000004;
   const ACE4_INHERIT_ONLY_ACE             = 0x00000008;
   const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG   = 0x00000010;
   const ACE4_FAILED_ACCESS_ACE_FLAG       = 0x00000020;
   const ACE4_IDENTIFIER_GROUP             = 0x00000040;
ToP   noToC   RFC3010 - Page 43
5.9.3.  ACE Access Mask

   The access_mask field contains values based on the following:

   Access                 Description
   READ_DATA              Permission to read the data of the file
   LIST_DIRECTORY         Permission to list the contents of a
   WRITE_DATA             Permission to modify the file's data
   ADD_FILE               Permission to add a new file to a
   APPEND_DATA            Permission to append data to a file
   ADD_SUBDIRECTORY       Permission to create a subdirectory to a
   READ_NAMED_ATTRS       Permission to read the named attributes
                          of a file
   WRITE_NAMED_ATTRS      Permission to write the named attributes
                          of a file
   EXECUTE                Permission to execute a file
   DELETE_CHILD           Permission to delete a file or directory
                          within a directory
   READ_ATTRIBUTES        The ability to read basic attributes
                          (non-acls) of a file
   WRITE_ATTRIBUTES       Permission to change basic attributes
                          (non-acls) of a file

   DELETE                 Permission to Delete the file
   READ_ACL               Permission to Read the ACL
   WRITE_ACL              Permission to Write the ACL
   WRITE_OWNER            Permission to change the owner
   SYNCHRONIZE            Permission to access file locally at the
                          server with synchronous reads and writes

   The bitmask constants used for the access mask field are as follows:

   const ACE4_READ_DATA            = 0x00000001;
   const ACE4_LIST_DIRECTORY       = 0x00000001;
   const ACE4_WRITE_DATA           = 0x00000002;
   const ACE4_ADD_FILE             = 0x00000002;
   const ACE4_APPEND_DATA          = 0x00000004;
   const ACE4_ADD_SUBDIRECTORY     = 0x00000004;
   const ACE4_READ_NAMED_ATTRS     = 0x00000008;
   const ACE4_WRITE_NAMED_ATTRS    = 0x00000010;
   const ACE4_EXECUTE              = 0x00000020;
   const ACE4_DELETE_CHILD         = 0x00000040;
   const ACE4_READ_ATTRIBUTES      = 0x00000080;
   const ACE4_WRITE_ATTRIBUTES     = 0x00000100;
ToP   noToC   RFC3010 - Page 44
   const ACE4_DELETE               = 0x00010000;
   const ACE4_READ_ACL             = 0x00020000;
   const ACE4_WRITE_ACL            = 0x00040000;
   const ACE4_WRITE_OWNER          = 0x00080000;
   const ACE4_SYNCHRONIZE          = 0x00100000;

5.9.4.  ACE who

   There are several special identifiers ("who") which need to be
   understood universally. Some of these identifiers cannot be
   understood when an NFS client accesses the server, but have meaning
   when a local process accesses the file. The ability to display and
   modify these permissions is permitted over NFS.

   Who                    Description
   "OWNER"                The owner of the file.
   "GROUP"                The group associated with the file.
   "EVERYONE"             The world.
   "INTERACTIVE"          Accessed from an interactive terminal.
   "NETWORK"              Accessed via the network.
   "DIALUP"               Accessed as a dialup user to the server.
   "BATCH"                Accessed from a batch job.
   "ANONYMOUS"            Accessed without any authentication.
   "AUTHENTICATED"        Any authenticated user (opposite of
   "SERVICE"              Access from a system service.

   To avoid conflict, these special identifiers are distinguish by an
   appended "@" and should appear in the form "xxxx@" (note: no domain
   name after the "@").  For example: ANONYMOUS@.

6.  File System Migration and Replication

   With the use of the recommended attribute "fs_locations", the NFS
   version 4 server has a method of providing file system migration or
   replication services.  For the purposes of migration and replication,
   a file system will be defined as all files that share a given fsid
   (both major and minor values are the same).

   The fs_locations attribute provides a list of file system locations.
   These locations are specified by providing the server name (either
   DNS domain or IP address) and the path name representing the root of
   the file system.  Depending on the type of service being provided,
   the list will provide a new location or a set of alternate locations
   for the file system.  The client will use this information to
   redirect its requests to the new server.
ToP   noToC   RFC3010 - Page 45
6.1.  Replication

   It is expected that file system replication will be used in the case
   of read-only data.  Typically, the file system will be replicated on
   two or more servers.  The fs_locations attribute will provide the
   list of these locations to the client.  On first access of the file
   system, the client should obtain the value of the fs_locations
   attribute.  If, in the future, the client finds the server
   unresponsive, the client may attempt to use another server specified
   by fs_locations.

   If applicable, the client must take the appropriate steps to recover
   valid filehandles from the new server.  This is described in more
   detail in the following sections.

6.2.  Migration

   File system migration is used to move a file system from one server
   to another.  Migration is typically used for a file system that is
   writable and has a single copy.  The expected use of migration is for
   load balancing or general resource reallocation.  The protocol does
   not specify how the file system will be moved between servers.  This
   server-to-server transfer mechanism is left to the server
   implementor.  However, the method used to communicate the migration
   event between client and server is specified here.

   Once the servers participating in the migration have completed the
   move of the file system, the error NFS4ERR_MOVED will be returned for
   subsequent requests received by the original server.  The
   NFS4ERR_MOVED error is returned for all operations except GETATTR.
   Upon receiving the NFS4ERR_MOVED error, the client will obtain the
   value of the fs_locations attribute.  The client will then use the
   contents of the attribute to redirect its requests to the specified
   server.  To facilitate the use of GETATTR, operations such as PUTFH
   must also be accepted by the server for the migrated file system's
   filehandles.  Note that if the server returns NFS4ERR_MOVED, the
   server MUST support the fs_locations attribute.

   If the client requests more attributes than just fs_locations, the
   server may return fs_locations only.  This is to be expected since
   the server has migrated the file system and may not have a method of
   obtaining additional attribute data.

   The server implementor needs to be careful in developing a migration
   solution.  The server must consider all of the state information
   clients may have outstanding at the server.  This includes but is not
   limited to locking/share state, delegation state, and asynchronous
ToP   noToC   RFC3010 - Page 46
   file writes which are represented by WRITE and COMMIT verifiers.  The
   server should strive to minimize the impact on its clients during and
   after the migration process.

6.3.  Interpretation of the fs_locations Attribute

   The fs_location attribute is structured in the following way:

   struct fs_location {
           utf8string      server<>;
           pathname4       rootpath;

   struct fs_locations {
           pathname4       fs_root;
           fs_location     locations<>;

   The fs_location struct is used to represent the location of a file
   system by providing a server name and the path to the root of the
   file system.  For a multi-homed server or a set of servers that use
   the same rootpath, an array of server names may be provided.  An
   entry in the server array is an UTF8 string and represents one of a
   traditional DNS host name, IPv4 address, or IPv6 address.  It is not
   a requirement that all servers that share the same rootpath be listed
   in one fs_location struct.  The array of server names is provided for
   convenience.  Servers that share the same rootpath may also be listed
   in separate fs_location entries in the fs_locations attribute.

   The fs_locations struct and attribute then contains an array of
   locations.  Since the name space of each server may be constructed
   differently, the "fs_root" field is provided.  The path represented
   by fs_root represents the location of the file system in the server's
   name space.  Therefore, the fs_root path is only associated with the
   server from which the fs_locations attribute was obtained.  The
   fs_root path is meant to aid the client in locating the file system
   at the various servers listed.

   As an example, there is a replicated file system located at two
   servers (servA and servB).  At servA the file system is located at
   path "/a/b/c".  At servB the file system is located at path "/x/y/z".
   In this example the client accesses the file system first at servA
   with a multi-component lookup path of "/a/b/c/d".  Since the client
   used a multi-component lookup to obtain the filehandle at "/a/b/c/d",
   it is unaware that the file system's root is located in servA's name
   space at "/a/b/c".  When the client switches to servB, it will need
   to determine that the directory it first referenced at servA is now
   represented by the path "/x/y/z/d" on servB.  To facilitate this, the
ToP   noToC   RFC3010 - Page 47
   fs_locations attribute provided by servA would have a fs_root value
   of "/a/b/c" and two entries in fs_location.  One entry in fs_location
   will be for itself (servA) and the other will be for servB with a
   path of "/x/y/z".  With this information, the client is able to
   substitute "/x/y/z" for the "/a/b/c" at the beginning of its access
   path and construct "/x/y/z/d" to use for the new server.

6.4.  Filehandle Recovery for Migration or Replication

   Filehandles for file systems that are replicated or migrated
   generally have the same semantics as for file systems that are not
   replicated or migrated.  For example, if a file system has persistent
   filehandles and it is migrated to another server, the filehandle
   values for the file system will be valid at the new server.

   For volatile filehandles, the servers involved likely do not have a
   mechanism to transfer filehandle format and content between
   themselves.  Therefore, a server may have difficulty in determining
   if a volatile filehandle from an old server should return an error of
   NFS4ERR_FHEXPIRED.  Therefore, the client is informed, with the use
   of the fh_expire_type attribute, whether volatile filehandles will
   expire at the migration or replication event.  If the bit
   FH4_VOL_MIGRATION is set in the fh_expire_type attribute, the client
   must treat the volatile filehandle as if the server had returned the
   NFS4ERR_FHEXPIRED error.  At the migration or replication event in
   the presence of the FH4_VOL_MIGRATION bit, the client will not
   present the original or old volatile file handle to the new server.
   The client will start its communication with the new server by
   recovering its filehandles using the saved file names.

7.  NFS Server Name Space

7.1.  Server Exports

   On a UNIX server the name space describes all the files reachable by
   pathnames under the root directory or "/".  On a Windows NT server
   the name space constitutes all the files on disks named by mapped
   disk letters.  NFS server administrators rarely make the entire
   server's file system name space available to NFS clients.  More often
   portions of the name space are made available via an "export"
   feature.  In previous versions of the NFS protocol, the root
   filehandle for each export is obtained through the MOUNT protocol;
   the client sends a string that identifies the export of name space
   and the server returns the root filehandle for it.  The MOUNT
   protocol supports an EXPORTS procedure that will enumerate the
   server's exports.
ToP   noToC   RFC3010 - Page 48
7.2.  Browsing Exports

   The NFS version 4 protocol provides a root filehandle that clients
   can use to obtain filehandles for these exports via a multi-component
   LOOKUP.  A common user experience is to use a graphical user
   interface (perhaps a file "Open" dialog window) to find a file via
   progressive browsing through a directory tree.  The client must be
   able to move from one export to another export via single-component,
   progressive LOOKUP operations.

   This style of browsing is not well supported by the NFS version 2 and
   3 protocols.  The client expects all LOOKUP operations to remain
   within a single server file system.  For example, the device
   attribute will not change.  This prevents a client from taking name
   space paths that span exports.

   An automounter on the client can obtain a snapshot of the server's
   name space using the EXPORTS procedure of the MOUNT protocol.  If it
   understands the server's pathname syntax, it can create an image of
   the server's name space on the client.  The parts of the name space
   that are not exported by the server are filled in with a "pseudo file
   system" that allows the user to browse from one mounted file system
   to another.  There is a drawback to this representation of the
   server's name space on the client: it is static.  If the server
   administrator adds a new export the client will be unaware of it.

7.3.  Server Pseudo File System

   NFS version 4 servers avoid this name space inconsistency by
   presenting all the exports within the framework of a single server
   name space.  An NFS version 4 client uses LOOKUP and READDIR
   operations to browse seamlessly from one export to another.  Portions
   of the server name space that are not exported are bridged via a
   "pseudo file system" that provides a view of exported directories
   only.  A pseudo file system has a unique fsid and behaves like a
   normal, read only file system.

   Based on the construction of the server's name space, it is possible
   that multiple pseudo file systems may exist.  For example,

   /a         pseudo file system
   /a/b       real file system
   /a/b/c     pseudo file system
   /a/b/c/d   real file system

   Each of the pseudo file systems are consider separate entities and
   therefore will have a unique fsid.
ToP   noToC   RFC3010 - Page 49
7.4.  Multiple Roots

   The DOS and Windows operating environments are sometimes described as
   having "multiple roots".  File systems are commonly represented as
   disk letters.  MacOS represents file systems as top level names.  NFS
   version 4 servers for these platforms can construct a pseudo file
   system above these root names so that disk letters or volume names
   are simply directory names in the pseudo root.

7.5.  Filehandle Volatility

   The nature of the server's pseudo file system is that it is a logical
   representation of file system(s) available from the server.
   Therefore, the pseudo file system is most likely constructed
   dynamically when the server is first instantiated.  It is expected
   that the pseudo file system may not have an on disk counterpart from
   which persistent filehandles could be constructed.  Even though it is
   preferable that the server provide persistent filehandles for the
   pseudo file system, the NFS client should expect that pseudo file
   system filehandles are volatile.  This can be confirmed by checking
   the associated "fh_expire_type" attribute for those filehandles in
   question.  If the filehandles are volatile, the NFS client must be
   prepared to recover a filehandle value (e.g. with a multi-component
   LOOKUP) when receiving an error of NFS4ERR_FHEXPIRED.

7.6.  Exported Root

   If the server's root file system is exported, one might conclude that
   a pseudo-file system is not needed.  This would be wrong.  Assume the
   following file systems on a server:

            /       disk1  (exported)
            /a      disk2  (not exported)
            /a/b    disk3  (exported)

   Because disk2 is not exported, disk3 cannot be reached with simple
   LOOKUPs.  The server must bridge the gap with a pseudo-file system.

7.7.  Mount Point Crossing

   The server file system environment may be constructed in such a way
   that one file system contains a directory which is 'covered' or
   mounted upon by a second file system.  For example:

            /a/b            (file system 1)
            /a/b/c/d        (file system 2)
ToP   noToC   RFC3010 - Page 50
   The pseudo file system for this server may be constructed to look

            /               (place holder/not exported)
            /a/b            (file system 1)
            /a/b/c/d        (file system 2)

   It is the server's responsibility to present the pseudo file system
   that is complete to the client.  If the client sends a lookup request
   for the path "/a/b/c/d", the server's response is the filehandle of
   the file system "/a/b/c/d".  In previous versions of the NFS
   protocol, the server would respond with the directory "/a/b/c/d"
   within the file system "/a/b".

   The NFS client will be able to determine if it crosses a server mount
   point by a change in the value of the "fsid" attribute.

7.8.  Security Policy and Name Space Presentation

   The application of the server's security policy needs to be carefully
   considered by the implementor.  One may choose to limit the
   viewability of portions of the pseudo file system based on the
   server's perception of the client's ability to authenticate itself
   properly.  However, with the support of multiple security mechanisms
   and the ability to negotiate the appropriate use of these mechanisms,
   the server is unable to properly determine if a client will be able
   to authenticate itself.  If, based on its policies, the server
   chooses to limit the contents of the pseudo file system, the server
   may effectively hide file systems from a client that may otherwise
   have legitimate access.

(page 50 continued on part 3)

Next Section