1 - 3 - 6 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - Q - R - S - T - U - V - W - X
version
Click on the red underlined text to get to the source
...
This definition of the NFS version 4 protocol replaces or obsoletes
the definition present in [RFC3010]. While portions of the two
...
... group attributes. Since these attributes are string
based (as opposed to the numeric uid/gid of previous versions of
NFS), translations may not be available and hence the changes
...
...
The NFS version 4 protocol is a further revision of the NFS protocol
defined already by versions ...
... version 4 protocol is a further revision of the NFS protocol
defined already by versions 2 [RFC1094] and 3 [RFC1813]. It retains
...
... RFC1094] and 3 [RFC1813]. It retains
the essential characteristics of previous versions: design for easy
recovery, independent of transport protocols, operating systems ...
... filesystems, simplicity, and good performance. The NFS version 4
revision has the following goals:
...
... supporting the RPCSEC_GSS protocol. Additionally, the NFS version
4 protocol provides a mechanism to allow clients and servers the
ability to negotiate security ...
... context for the reader, the major features of
NFS version 4 protocol will be reviewed in brief. This will be done
to provide an appropriate context for both the reader who is familiar
...
... to provide an appropriate context for both the reader who is familiar
with the previous versions of the NFS protocol and the reader that is
new to the NFS ...
... RPC) mechanisms used for the NFS
version 4 protocol are those defined in [RFC1831] and [RFC1832]. To
...
... integrity, and privacy to the NFS version 4 protocol.
Kerberos V5 will be used as described in [RFC1964 ...
... server public key by the NFS version 4 protocol. With the use of
RPCSEC_GSS, other mechanisms may also be specified and used for NFS ...
... in-band security negotiation, the NFS version 4 protocol
has added a new operation which provides the client a method ...
...
A significant departure from the previous versions of the NFS
protocol is the introduction of the COMPOUND procedure. For the NFS ...
... protocol is the introduction of the COMPOUND procedure. For the NFS
version 4 protocol, there are two RPC procedures, NULL and COMPOUND.
The COMPOUND procedure is defined in terms of operations and these
...
... LOOKUP, OPEN, and READ operations in a single COMPOUND RPC.
With previous versions of the NFS protocol, this type of single
request was not possible.
...
...
The NFS version 4 protocol continues to have the client refer to a
file or directory at the server by a "filehandle". The COMPOUND
...
...
The general filesystem model used for the NFS version 4 protocol is
the same as previous versions. The server filesystem is hierarchical
...
... NFS version 4 protocol is
the same as previous versions. The server filesystem is hierarchical
with the regular files contained within being treated as opaque byte
...
...
The NFS version 4 protocol does not require a separate protocol to
provide for the initial mapping between path name and filehandle.
Instead of using the older MOUNT protocol for this mapping, the
...
...
In previous versions of the NFS protocol, the filehandle provided by
the server was guaranteed to be valid ...
...
meet. For the NFS version 4 protocol, this requirement has been
relaxed by introducing another type of filehandle, volatile. With
...
...
The NFS version 4 protocol introduces three classes of filesystem or
file attributes. Like the additional filehandle type, the
...
... directory and file access control beyond the model used in previous
versions of the NFS protocol. The ACL definition allows for
...
...
The NFS version 4 protocol introduces OPEN and CLOSE operations. The
OPEN operation provides a single point where file lookup, creation,
...
... structured so that an RPC callback mechanism is not required. This
is a departure from the previous versions of the NFS file locking
protocol, Network ...
...
The file, attribute, and directory caching for the NFS version 4
protocol is similar to previous versions. Attributes and directory
...
... NFS version 4
protocol is similar to previous versions. Attributes and directory
information are cached for a duration determined by the client. At
...
...
The major addition to NFS version 4 in the area of caching is the
ability of the server to delegate certain responsibilities to the
client ...
... Stable Storage
NFS version 4 servers must be able to recover without data
loss from multiple power failures (including cascading
power failures, that is, several power failures in quick
...
... syntax and semantics to describe the data types of the NFS
version 4 protocol are defined in the XDR [RFC1832] and RPC ...
... RPC)
application that uses RPC version 2 and the corresponding eXternal
Data Representation (XDR) as defined in [RFC1831 ...
... Historically, NFS version 2 and version 3 servers have resided on
port 2049. The registered port ...
...
Where an NFS version 4 implementation supports operation over the IP
network protocol, the supported transports between NFS ...
... interoperability, an NFS version 4 implementation MUST support
operation over the TCP transport protocol ...
... authentication
model for NFS version 4 has moved from machine-based to principal-
based. However, this modification of the authentication ...
... number of expected client machines. It is intended that NFS version
4 will not modify this connection management model. NFS ...
... connection management model. NFS version 4
clients that violate this assumption can expect scaling issues on the
...
... TCP, the NFS version 4 server MUST NOT silently drop the request,
except if the transport connection has been broken. Given such a
...
... transport connection has been broken. Given such a
contract between NFS version 4 clients and servers, clients MUST NOT
...
... transport connection
break will eventually be indicated to the NFS version 4 client. The
client ...
... pseudo flavor is needed for NFS
version 3 since the security negotiation is done via the MOUNT
protocol.
...
...
With the NFS version 4 server potentially offering multiple security
mechanisms, the client needs a method ...
...
Based on the assumption that each NFS version 4 client and server
must support a minimum set of security ...
... client needs a filehandle to
initiate communication with the server. With the NFS version 2
protocol [RFC1094] and the NFS ...
... protocol [RFC1094] and the NFS version 3 protocol [RFC1813], there
exists an ancillary protocol to obtain this first filehandle. The
...
... LOOKUP operation in
the NFS version 2 and 3 protocols, it has been demonstrated that the
MOUNT protocol is unnecessary for viable interaction between NFS
...
...
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 ...
...
In the NFS version 2 and 3 protocols, there was one type of
filehandle with a single set of semantics. This type of filehandle
...
... semantics. This type of filehandle
is termed "persistent" in NFS Version 4. The semantics of a
persistent filehandle remain the same as before. A new type of
...
... persistent filehandle remain the same as before. A new type of
filehandle introduced in NFS Version 4 is the "volatile" filehandle,
which attempts to accommodate certain server environments.
...
... 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
...
... 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
...
...
These MUST be supported by every NFS version 4 client and server in
order to ensure a minimum level of interoperability ...
... 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 ...
... 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
...
...
To provide a greater degree of compatibility with previous versions
of NFS (i.e., v2 and v3), which identified users and groups ...
... ACLs. For example, the enforcement for
NFS version 4 access may be different from the enforcement for local
access, and both may be different from the enforcement for access
through other protocols such as SMB. So it may be useful for a
...
... The remaining bits are not defined by this protocol and MUST NOT be
used. The minor version mechanism must be used to define further bit
usage.
...
...
While the NFS version 4 client could simply fabricate a fileid
corresponding to what mounted_on_fileid provides (and if the server
...
... With the use of the recommended attribute "fs_locations", the NFS
version 4 server has a method of providing filesystem migration or
...
... portions of the name space are made available via an "export"
feature. In previous versions of the NFS protocol, the root
...
...
This style of browsing is not well supported by the NFS version 2 and
3 protocols. The client expects all LOOKUP operations ...
...
NFS version 4 servers avoid this name space inconsistency by
presenting all the exports within the framework ...
... top level names. NFS
version 4 servers for these platforms can construct a pseudo file
system above these root ...
... lookup request
for the path "/a/b/c/d", the server's response is the filehandle of
the filesystem "/a/b/c/d". In previous versions of the NFS protocol,
the server would respond with the filehandle of directory "/a/b/c/d"
...
... CREATE, ACCESS) need to be replaced. The NFS version 4 protocol has
an OPEN operation that subsumes the NFS version 3 ...
... version 4 protocol has
an OPEN operation that subsumes the NFS version 3 methodology of
LOOKUP, CREATE ...
... where there is no local disk and all file access is from an NFS
version 4 server.
o The string should be different for each server network ...
...
o For a user level NFS version 4 client, it should contain
additional information to distinguish the client ...
... - The timestamp of when the NFS version 4 software was first
installed on the client (though this is subject ...
... stored in a file, because the file might only be accessible
over NFS version 4).
- A true random number ...
...
With NFS version 3, there was no notion of a stateid so there was no
way to tell if the application process of the client sending the READ
...
...
Thus, the NFS version 4 LOCK operation does not need to distinguish
between advisory and mandatory record locks. It is the NFS version 4 ...
... version 4 LOCK operation does not need to distinguish
between advisory and mandatory record locks. It is the NFS version 4
server's processing of the READ and WRITE operations that introduces
the distinction.
...
... Some clients require the support of blocking locks. The NFS version
4 protocol must not rely on a callback mechanism and therefore is
unable to notify a client when a previously denied lock has been
...
... CREATE flag, also subsumes the CREATE
operation for regular files as used in previous versions of the NFS
protocol. This allows a create ...
... old server is left to the server implementations. It is not
specified by the NFS version 4 protocol.
...
... Providing distributed cache coherence is a difficult problem and
previous versions of the NFS protocol have not attempted it.
Instead, several NFS ...
...
The NFS version 4 protocol uses many techniques similar to those that
have been used in previous protocol versions. The NFS ...
... NFS version 4 protocol uses many techniques similar to those that
have been used in previous protocol versions. The NFS version 4
...
... have been used in previous protocol versions. The NFS version 4
protocol does not provide distributed cache coherence. However, it
...
...
In addition, the NFS version 4 protocol introduces a delegation
mechanism which allows many decisions normally made by the server ...
...
Caching techniques used in previous versions of the NFS protocol have
been successful in providing good performance ...
... cache revalidation requests.
The previous versions of the NFS protocol repeat their file data
cache ...
...
The NFS version 4 protocol provides more aggressive caching
strategies with the following design goals:
...
... server semantics.
o Provide the same caching benefits as previous versions of the NFS
protocol when unable to provide the more aggressive model.
...
... delegation reclaim reconciles
three principles of the NFS version 4 protocol:
o Upon reclaim, a client ...
... Share reservations and record locks are the facilities the NFS
version 4 protocol provides to allow applications to coordinate
access by providing mutual exclusion facilities. The NFS version 4 ...
... version 4 protocol provides to allow applications to coordinate
access by providing mutual exclusion facilities. The NFS version 4
protocol's data caching must be implemented such that it does not
invalidate the assumptions that those using these facilities depend
...
... In order to avoid invalidating the sharing assumptions that
applications rely on, NFS version 4 clients should not provide cached
data to applications or modify it on behalf of an application when it
...
... Delegation") two additional rules apply. Note that these rules are
obeyed in practice by many NFS version 2 and version 3 clients.
...
... specifying DENY=NONE) to parallel the NFS version 3 protocol's
practice for the benefit of users assuming this degree of cache
...
... will work on a local filesystem. However, they may not work with the
NFS version 4 protocol unless clients refrain from data caching.
...
... according to the filesystem object to which the data belongs. For
NFS version 3 clients, the typical practice has been to assume for
the purpose of caching that distinct filehandles represent distinct
...
...
In the NFS version 4 protocol, there is now the possibility to have
significant deviations from a "one filehandle per object" model
because a filehandle may be constructed on the basis of the object's
...
... By providing a method to differentiate filehandles, the NFS version 4
protocol alleviates a potential functional regression in comparison
...
... comparison
with the NFS version 3 protocol. Without this method, caching
inconsistencies within the same client ...
... inconsistencies within the same client could occur and this has not
been present in previous versions of the NFS protocol. Note that it
is possible to have such inconsistencies with applications executing
...
... For the purposes of data caching, the following steps allow an NFS
version 4 client to determine whether two distinct filehandles denote
the same server side ...
... client holding the
delegation has a modified version of the file. If the client's copy
of the delegated file is not modified (data or size), the server can
...
... A client may validate its cached version of attributes for a file by
fetching just both the change and time_access attributes and assuming
that if the change attribute has the same value as it did when the
...
... from the server. Nor is the client encouraged to maintain a modified
version of time_access in its cache, since this would mean that the
client ...
... NFS protocol that can evolve as the
need arises, the NFS version 4 protocol contains the rules and
framework to allow for future minor changes or versioning.
...
...
The base assumption with respect to minor versioning is that any
future accepted minor version must follow the IETF process and be
documented in a standards track RFC. Therefore, each minor version
number ...
... version must follow the IETF process and be
documented in a standards track RFC. Therefore, each minor version
number will correspond to an RFC. Minor version zero of the NFS
...
... IETF process and be
documented in a standards track RFC. Therefore, each minor version
number will correspond to an RFC. Minor version zero of the NFS
version 4 ...
... version zero of the NFS
version 4 protocol is represented by this RFC. The COMPOUND
procedure will support the encoding of the minor version ...
... version 4 protocol is represented by this RFC. The COMPOUND
procedure will support the encoding of the minor version being
requested by the client.
...
... The following items represent the basic rules for the development of
minor versions. Note that a future minor version may decide to
modify or add to the following rules as part of the minor version ...
... basic rules for the development of
minor versions. Note that a future minor version may decide to
modify or add to the following rules as part of the minor version
...
... versions. Note that a future minor version may decide to
modify or add to the following rules as part of the minor version
definition.
...
... NFS program.
2. Minor versions may add operations to the COMPOUND and
CB_COMPOUND procedures.
...
... RPC model.
2.1 Minor versions may append attributes to GETATTR4args, bitmap4,
and GETATTR4res.
...
... for future growth or adaptation.
2.2 Minor version X must append any new attributes after the last
documented attribute.
...
... burdensome.
3. Minor versions must not modify the structure of an existing
operation's arguments or results.
...
... for a single operation is too burdensome. New operations should
be added instead of modifying existing structures for a minor
version.
This rule does not preclude the following adaptations in a minor
...
... values
4. Minor versions may not modify the structure of existing
attributes.
...
...
This prevents the potential reuse of a particular operation
"slot" in a future minor version.
6. Minor versions ...
... flag bits or enumeration values.
8. Minor versions may declare an operation as mandatory to NOT
implement.
...
... XDR decode error. This approach allows for
the obsolescence of an operation while maintaining its structure
so that a future minor version can reintroduce the operation.
8.1 Minor versions ...
... version can reintroduce the operation.
8.1 Minor versions may declare attributes mandatory to NOT
implement.
...
... implement.
8.2 Minor versions may declare flag bits or enumeration values as
mandatory to NOT implement.
...
... mandatory to NOT implement.
9. Minor versions may downgrade features from mandatory to
recommended, or recommended to optional.
...
... recommended, or recommended to optional.
10. Minor versions may upgrade features from optional to recommended
or recommended to mandatory.
...
...
11. A client and server that support minor version X must support
minor versions 0 (zero) through X-1 as well.
...
... client and server that support minor version X must support
minor versions 0 (zero) through X-1 as well.
12. No new features may be introduced as mandatory in a minor
...
...
12. No new features may be introduced as mandatory in a minor
version.
This rule allows for the introduction of new functionality and
...
... client MUST NOT attempt to use a stateid, filehandle, or
similar returned object from the COMPOUND procedure with minor
version X for another COMPOUND procedure with minor version Y,
where X != Y.
...
... similar returned object from the COMPOUND procedure with minor
version X for another COMPOUND procedure with minor version Y,
where X != Y.
...
...
The primary issue in which NFS version 4 needs to deal with
internationalization, or I18N, is with respect to file names and
...
... There are three UTF-8 string types defined for NFS version 4:
utf8str_cs, utf8str_cis, and utf8str_mixed. Separate profiles are
...
... Stringprep discusses Unicode characters, whereas NFS version 4
renders UTF-8 characters. Since there is a one to one mapping from
...
... Every use of the utf8str_cs type definition in the NFS version 4
protocol specification follows the profile ...
... UTF-8 characters.
Its primary use in NFS Version 4 is for naming components and
pathnames. Components and pathnames are stored on the server's
filesystem. Two valid ...
... profile. If the strings are two names
inside a directory, the NFS version 4 server will need to either:
o disallow the creation of a second name if it's post processed form
...
... case-insensitive comparisons. However, if
the NFS version 4 file server supports the case_insensitive
filesystem attribute, and if case_insensitive is true, the NFS
...
... filesystem attribute, and if case_insensitive is true, the NFS
version 4 server MUST use Table B.2 (in addition to Table B1) when
processing utf8str_cs strings, and the NFS version 4 ...
... version 4 server MUST use Table B.2 (in addition to Table B1) when
processing utf8str_cs strings, and the NFS version 4 client MUST
assume Table B.2 (in addition to Table B.1) are being used.
...
... If the case_preserving attribute is present and set to false, then
the NFS version 4 server MUST use table B.2 to map case when
processing utf8str_cs strings. Whether the server maps from lower to
upper case or the upper to lower case is an implementation
...
... Every use of the utf8str_cis type definition in the NFS version 4
protocol specification follows the profile ...
... Every use of the utf8str_mixed type definition in the NFS version 4
protocol specification follows the profile ...
... is fully qualified domain name. Its primary use in NFS Version 4 is
for naming principals identified in an Access Control Entry ...
... NFS4ERR_MINOR_VERS_MISMATCH
The server has received a request that
specifies an unsupported minor version. The
server must return a COMPOUND4res with a zero
length operations result array.
...
... NFS4ERR_SERVERFAULT An error occurred on the server which does not
map to any of the legal NFS version 4 protocol
error values. The client should translate this
...
... signaling and is constructed in a similar fashion as the NFS version
4 program. The procedures CB_NULL and CB_COMPOUND are defined in the
same way as NULL and COMPOUND are within the NFS program. The
...
...
NFS version 4 operations that modify the filesystem are synchronous.
When an operation is successfully completed at the server, the client ...
... and default value for this field is 0 (zero). This field will be
used by future minor versions such that the client can communicate to
the server what minor version ...
... versions such that the client can communicate to
the server what minor version is being requested. If the server
receives a COMPOUND procedure with a minorversion field value that it
does not support, the server MUST return an error of
...
... minorversion field is non-zero and the server does not support the
minor version, the server returns an error of
NFS4ERR_MINOR_VERS_MISMATCH. Therefore, the
NFS4ERR_MINOR_VERS_MISMATCH error takes precedence over all other
...
...
In the NFS version 2 protocol, the only reliable way to determine
whether an operation was allowed was to try it and see if it
succeeded or failed. Using the ACCESS operation in the NFS ...
... whether an operation was allowed was to try it and see if it
succeeded or failed. Using the ACCESS operation in the NFS version 4
protocol, the client can ask the server to indicate whether or not
...
... semantics of previous NFS
versions in allowing LOOKUP requests to cross mountpoints on the
server. The client ...
... be limited to paths that lead to exported filesystems.
Note: previous versions of the protocol assigned special semantics to
the names "." and "..". NFS ...
... semantics to
the names "." and "..". NFS version 4 assigns no special semantics
to these names. The LOOKUPP operator must be used to lookup ...
... RFC1813]. As
in NFS version 3, this mechanism provides reliable exclusive
creation. Exclusive create is invoked when the how parameter is
...
... the server must return NFS4ERR_ACCESS. Note that since the NFS
version 4 protocol does not impose any requirement that READs and
WRITEs issued for an open file have the same credentials ...
... open_owner4s or stop using them for indefinite periods of time. The
latter situation is why the NFS version 4 protocol does not have an
explicit operation to exit an open_owner4: such an operation is of no
...
... RFC2055], [RFC2224]. The intent for NFS version 4 is that the
public filehandle (represented by the PUTPUBFH operation) be used as
a method ...
...
With the NFS version 2 and 3 public filehandle, the client is able to
specify whether the path name provided in the LOOKUP ...
... discussion of the functionality. With NFS version 4, that type of
specification is not directly available in the LOOKUP operation. The
...
... reason for this is because the component separators needed to specify
absolute vs. relative are not allowed in NFS version 4. Therefore,
the client ...
... namespace
has been made available. These same warnings apply to NFS version 4.
It is likely, therefore that because of server implementation
details, an NFS ...
... It is likely, therefore that because of server implementation
details, an NFS version 3 absolute public filehandle lookup may
behave differently than an NFS ...
... lookup may
behave differently than an NFS version 4 absolute resolution.
There is a form of security negotiation ...
... method is not available with NFS version 4 as filehandles are not
overloaded with special meaning and therefore do not provide the same
...
...
Since some servers will not be returning "." and ".." entries as has
been done with previous versions of the NFS protocol, the client that
...
...
NFS versions 2 and 3 required a different operator RMDIR for
directory removal and REMOVE for non-directory removal. This allowed
...
... file type. The implementor of an NFS version 4
client's entry points from the unlink() and rmdir() system calls
...
... client may specify a request that emulates the
functionality of the SETATTR guard mechanism of NFS version 3. Since
the function of the guard mechanism is to avoid changes to the file
attributes based on stale information, delays between checking of the
...
... to compromise this function, as would the corresponding delay in the
NFS version 4 emulation. Therefore, NFS version 4 servers should
...
... NFS version 4 emulation. Therefore, NFS version 4 servers should
take care to avoid such delays, to the degree possible, when
executing such a request.
...
... filesystem metadata to stable storage before returning results. This
corresponds to the NFS version 2 protocol semantics. Any other
behavior constitutes a protocol violation. If stable is DATA_SYNC4,
...
... consistent during a single instance of the NFS version 4 protocol
service and must be unique between instances of the NFS ...
... service and must be unique between instances of the NFS version 4
protocol server, where uncommitted data may be lost.
...
... client to detect different
instances of an NFS version 4 protocol server over which cached,
uncommitted data may be lost. In the most likely case, the verifier ...
... and/or reduction of CPU utilization, users of NFS version 4
implementations may choose to not use security mechanisms that enable
...
...
The NFS version 4 protocol provides for the association of named
attributes to files. The name space ...
... registration of
NFS version 4 named attributes. Registration will be achieved
through the publication of an Informational RFC and will require not
...
... the corresponding r_addr field of a clientaddr4 structure. The NFS
version 4 protocol depends on the syntax and semantics of these
...
... "udp6" - UDP over IP version 6
Note: the '"' marks are used for delimiting the strings for this
...
... Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373(-> 3513(-> 4291draft)), July 1998. ...
... Eisler, M., "NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS ...
... Linn, J., "Generic Security Service Application Program Interface, Version 2, Update 1", RFC 2743prop, January 2000. ...
... Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC 3010(-> 3530prop), December 2000. ...
... The Unicode Consortium, "The Unicode Standard, Version 3.0", Addison-Wesley Developers Press, Reading, MA, 2000. ISBN 0-201-61633-5. More information available at: http://www.unicode.org/ ...
... Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995. ...
... Association, Berkeley, CA, Summer 1985. The basic paper describing the SunOS implementation of the NFS version 2 protocol, and discusses the goals, protocol specification and trade- offs. ...
... The Open Group, Protocols for Interworking: XNFS, Version 3W, The Open Group, 1010 El Camino Real Suite 380, Menlo Park, CA 94025, ISBN 1-85912-184-5, February 1998. HTML ...
... Group, 1010 El Camino Real Suite 380, Menlo Park, CA 94025, ISBN 1-85912-184-5, February 1998. HTML version available: http://www.opengroup.org ...