in Index   Prev   Next

RFC 3010

NFS version 4 Protocol

Pages: 212
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 server.

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 entry/slot 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 NFS4ERR_FHEXPIRED. 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 steps. 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 space.
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 well. 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, symlink)
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 system. archive 14 boolean R/W Whether or not this file has been archived since the time of last modification (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 insensitive? case_preserving 17 boolean READ Is filename case on this file system preserved?
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: quota_avail_soft 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. quota_avail_hard 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. quota_used 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 above. 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. ACE4_FILE_INHERIT_ACE Can be placed on a directory and indicates that this ACE should be added to each new non-directory file created. ACE4_DIRECTORY_INHERIT_ACE Can be placed on a directory and indicates that this ACE should be added to each new directory created. ACE4_INHERIT_ONLY_ACE 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 flags. ACE4_NO_PROPAGATE_INHERIT_ACE
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 directory WRITE_DATA Permission to modify the file's data ADD_FILE Permission to add a new file to a directory APPEND_DATA Permission to append data to a file ADD_SUBDIRECTORY Permission to create a subdirectory to a directory 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 ANONYMOUS) "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