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
NFS
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 ...
... uid/gid of previous versions of
NFS), translations may not be available and hence the changes
made.
...
... The NFS version 4 protocol is a further revision of the NFS protocol
defined already by versions 2 [RFC1094 ...
... operating systems and
filesystems, simplicity, and good performance. The NFS version 4
revision has the following goals:
...
... working group in
supporting the RPCSEC_GSS protocol. Additionally, the NFS version
4 protocol provides a mechanism to allow clients and servers the
...
... To provide a reasonable 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 ...
... 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 protocols. For the reader new to the NFS ...
... versions of the NFS protocol and the reader that is
new to the NFS protocols. For the reader new to the NFS protocols,
there is still a fundamental knowledge that is expected. The reader
...
... NFS protocol and the reader that is
new to the NFS protocols. For the reader new to the NFS protocols,
there is still a fundamental knowledge that is expected. The reader
should be familiar with the XDR ...
... XDR) and Remote Procedure Call (RPC) mechanisms used for the NFS
version 4 protocol are those defined in [RFC1831 ...
... version 4 protocol. With the use of
RPCSEC_GSS, other mechanisms may also be specified and used for NFS
version 4 security ...
... To enable in-band security negotiation, the NFS version 4 protocol
has added a new operation which provides the client ...
...
A significant departure from the previous versions of the NFS
protocol is the introduction of the COMPOUND procedure. For the NFS
...
... versions of the NFS
protocol is the introduction of the COMPOUND procedure. For the NFS
version 4 protocol, there are two RPC ...
... RPC procedures, NULL and COMPOUND.
The COMPOUND procedure is defined in terms of operations and these
operations correspond more closely to the traditional NFS procedures.
With the use of the COMPOUND procedure, the client ...
... RPC.
With previous versions of the NFS protocol, this type of single
request was not possible.
...
...
The general filesystem model used for the NFS version 4 protocol is
the same as previous versions ...
... internationalization.
The NFS version 4 protocol does not require a separate protocol to
provide for the initial mapping between path name and filehandle.
...
...
In previous versions of the NFS protocol, the filehandle provided by
the server was guaranteed to be valid or persistent for the lifetime ...
... requirement has been difficult to
meet. For the NFS version 4 protocol, this requirement has been
...
... classification of file attributes has been done to ease server
implementations along with extending the overall functionality of the
NFS protocol. This attribute model is structured to be extensible
such that new attributes can be introduced in minor revisions of the
protocol without requiring significant rework.
...
... The three classifications are: mandatory, recommended and named
attributes. This is a significant departure from the previous
attribute model used in the NFS protocol. Previously, the attributes
for the filesystem and file objects were a fixed set of mainly UNIX
...
... access control beyond the model used in previous
versions of the NFS protocol. The ACL definition allows for
specification of user and group ...
...
The NFS version 4 protocol introduces OPEN and CLOSE operations. The
OPEN operation provides a single point where file lookup ...
... version 4 protocol, the support for byte range file
locking is part of the NFS protocol. The file locking support is
structured so that an RPC callback mechanism is not required. This
...
... RPC callback mechanism is not required. This
is a departure from the previous versions of the NFS file locking
protocol, Network Lock Manager (NLM). The state ...
... locks is maintained at the server under a lease-based model. The
server defines a single lease period for all state held by a NFS
client. If the client ...
...
The file, attribute, and directory caching for the NFS version 4
protocol is similar to previous versions ...
... ranges in question should be used.
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 The "client" is the entity that accesses the NFS server's
resources. The client may be an application which contains
...
... resources. The client may be an application which contains
the logic to access the NFS server directly. The client
may also be the traditional operating system ...
...
Stable Storage
NFS version 4 servers must be able to recover without data
loss from multiple power failures (including cascading
...
...
Some examples of stable storage that are allowable for an
NFS server include:
1. Media commit of data, that is, the modified data has
...
...
The syntax and semantics to describe the data types of the NFS
version 4 protocol are defined in the XDR ...
... RFC2203] MUST be used as
the mechanism to deliver stronger security for the NFS version 4
protocol.
...
... port 2049. The registered port 2049 [RFC3232] for the NFS protocol
should be the default configuration. Using the registered port for
...
... should be the default configuration. Using the registered port for
NFS services means the NFS client ...
... firewalls.
Where an NFS version 4 implementation supports operation over the IP
network protocol, the supported transports ...
... version 4 implementation supports operation over the IP
network protocol, the supported transports between NFS and IP MUST be
among the IETF ...
... SCTP. To enhance the possibilities for
interoperability, an NFS version 4 implementation MUST support
operation over the TCP ...
... Security Considerations section, the authentication
model for NFS version 4 has moved from machine-based to principal-
...
... management model from whole machine-based to one based on a per user
model. In particular, NFS over TCP client implementations have
...
... traffic for multiple users over a common
TCP connection between an NFS client and server. This has been true,
regardless whether the NFS ...
... NFS client and server. This has been true,
regardless whether the NFS client is using AUTH_SYS, AUTH ...
... DH,
RPCSEC_GSS or any other flavor. Similarly, NFS over TCP server
implementations have assumed such a model and thus scale the
...
... management in proportion to the
number of expected client machines. It is intended that NFS version
4 will not modify this connection management ...
... transport such as
TCP, the NFS version 4 server MUST NOT silently drop the request,
except if the transport connection ...
... except if the transport connection has been broken. Given such a
contract between NFS version 4 clients and servers, clients ...
... inform a peer when the other peer has broken the connection (for
example, when an NFS server reboots), the NFS version 4 client ...
... to the server. If the server has died, the transport connection
break will eventually be indicated to the NFS version 4 client. The
...
... pseudo flavor is presented here as a mapping aid to the
implementor. Because this NFS protocol includes a method to
negotiate security ...
... pseudo flavor is not needed. The pseudo flavor is needed for NFS
version 3 since the security negotiation ...
... method to determine or negotiate which
mechanism is to be used for its communication with the server. The
NFS server may have multiple points within its filesystem name space
that are available for use by NFS ...
... NFS server may have multiple points within its filesystem name space
that are available for use by NFS clients. In turn the NFS server
...
... that are available for use by NFS clients. In turn the NFS server
may be configured such that each of these entry points may have
different or multiple security mechanisms ...
... triples. During communication with the server, the client may
receive an NFS error of NFS4ERR_WRONGSEC. This error allows the
server to notify the client that the security ...
... RPC
(described later) MUST mutually authenticate the NFS server to the
principal that acquired the clientid (also described later), using
...
... security mechanism under RPCSEC_GSS is being used,
the NFS server, MUST identify itself in GSS-API via a
GSS ...
... user name/password
pair, and if the user that the NFS server is authenticating to has a
public key certificate, then it works.
...
... public key certificate, then it works.
In situations where the NFS client uses LIPKEY and uses a per-host ...
...
The filehandle in the NFS protocol is a per server unique identifier
for a filesystem object. The contents of the filehandle are opaque ...
...
The operations of the NFS protocol are defined in terms of one or
more filehandles. Therefore, the client needs a filehandle to
...
... more filehandles. Therefore, the client needs a filehandle to
initiate communication with the server. With the NFS version 2
protocol [RFC1094 ...
... RPC program number 100005, provides the mechanism of
translating a string based filesystem path name to a filehandle which
can then be used by the NFS protocols.
The MOUNT protocol has deficiencies in the area of security ...
... of the public filehandle in combination with 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 ...
... NFS version 2 and 3 protocols, it has been demonstrated that the
MOUNT protocol is unnecessary for viable interaction between NFS
client and server.
...
... client and server.
Therefore, the NFS version 4 protocol will not use an ancillary
protocol for translation from string based path names to a
...
... root of the filesystem name space
at the NFS server. The client uses or starts with the ROOT ...
... LOOKUP operation. A complete discussion of the server
name space is in the section "NFS Server Name Space".
...
...
In the NFS version 2 and 3 protocols, there was one type of
filehandle with a single set of semantics ...
... filehandle with a single set of semantics. This type of filehandle
is termed "persistent" in NFS Version 4. The semantics of a
...
... semantics of a
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.
...
... 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 filesystem is migrated, the new NFS ...
... NFS server must
honor the same filehandle value as it did in the server's previous
instantiation. Similarly, if the filesystem is migrated, the new NFS
server must honor the same filehandle as the old NFS server.
...
... instantiation. Similarly, if the filesystem is migrated, the new NFS
server must honor the same filehandle as the old NFS server.
The persistent filehandle will be become stale or invalid when the
...
... 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 ...
... new needs arise and it provides no way to indicate non-support. With
the NFS version 4 protocol, the client is able query ...
... 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 ...
... 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
...
...
Named attributes are intended for data needed by applications rather
than by an NFS client implementation. NFS implementors ...
... than by an NFS client implementation. NFS implementors are strongly
encouraged to define their new attributes as 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 ...
...
These attributes are not supported by direct encoding in the NFS
Version 4 protocol but are accessed by string names rather than
...
... compatibility with previous versions
of NFS (i.e., v2 and v3), which identified users and groups by 32-bit
...
... 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
...
... the requester's access.
The NFS version 4 ACL model is quite rich. Some server platforms may
...
... access control functionality that goes beyond the UNIX-style
mode attribute, but which is not as rich as the NFS ACL model. So
that users can take advantage of this more limited functionality, the
...
... ACLs as long as it follows the
guidelines for mapping between its ACL model and the NFS version 4
ACL ...
... multiple modules that enforce 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
...
... request with NFS4ERR_ATTRNOTSUPP.
Example: suppose a server can enforce NFS ACLs for NFS access but
...
... Example: suppose a server can enforce NFS ACLs for NFS access but
cannot enforce ACLs for local access. If arbitrary processes can run
...
... domain. 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
...
... 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, even if none of the access methods
on the server understands the identifiers ...
...
With the use of the recommended attribute "fs_locations", the NFS
version 4 server has a method ...
... NFS Server Name Space ...
... the name space constitutes all the files on disks named by mapped
disk letters. NFS server administrators rarely make the entire
server's filesystem name space ...
... administrators rarely make the entire
server's filesystem name space available to NFS clients. More often
portions of the name space ...
... 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;
...
... LOOKUP operations.
This style of browsing is not well supported by the NFS version 2 and
3 protocols. The client ...
... roots". Filesystems are commonly represented as
disk letters. MacOS represents filesystems as top level names. NFS
version 4 servers for these platforms can construct a pseudo ...
... preferable that the server provide persistent filehandles for the
pseudo filesystem, the NFS client should expect that pseudo file
system ...
... 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
...
... 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"
within the filesystem "/a/b".
...
... within the filesystem "/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.
...
...
Integrating locking into the NFS protocol necessarily causes it to be
stateful. With the inclusion of share reservations the protocol
becomes substantially more dependent on state ...
... becomes substantially more dependent on state than the traditional
combination of NFS and NLM [XNFS]. There are three components to
making this state ...
... API. In
order to correctly implement share semantics, the previous NFS
protocol mechanisms used when a file is opened or created ...
... LOOKUP,
CREATE, ACCESS) need to be replaced. The NFS version 4 protocol has
an OPEN operation that subsumes the NFS ...
... NFS version 4 protocol has
an OPEN operation that subsumes the NFS version 3 methodology of
LOOKUP ...
... that requires the string to be recorded in a local file because
this precludes the use of the implementation in an environment
where there is no local disk and all file access is from an NFS
version 4 server.
...
... previously mentioned caution about using information that is
stored in a file, because the file might only be accessible
over NFS version 4).
...
... WRITE*_LT for a WRITE operation).
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 ...
... server always checks for record locks during I/O requests.
Thus, the NFS version 4 LOCK operation does not need to distinguish
between advisory and mandatory record locks. It is the NFS ...
... NFS 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
...
...
Locking is different than most NFS operations as it requires "at-
most-one" semantics that are not provided by ONCRPC. ONCRPC over a
...
...
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 ...
... CREATE
operation for regular files as used in previous versions of the NFS
protocol. This allows a create with a share to be done atomically.
...
... the old server is left to the server implementations. It is not
specified by the NFS version 4 protocol.
...
... Client-side caching of data, of file attributes, and of file names is
essential to providing good performance with the NFS protocol.
Providing distributed cache coherence is a difficult problem and
...
... cache coherence is a difficult problem and
previous versions of the NFS protocol have not attempted it.
Instead, several NFS client ...
... versions of the NFS protocol have not attempted it.
Instead, several NFS client implementation techniques have been used
to reduce the problems that a lack of coherence poses for users.
...
... client behavior.
The NFS version 4 protocol uses many techniques similar to those that
have been used in previous protocol versions ...
... version 4 protocol uses many techniques similar to those that
have been used in previous protocol versions. The NFS version 4
protocol does not provide distributed cache ...
...
Caching techniques used in previous versions of the NFS protocol have
been successful in providing good performance. However, several
...
... This penalty may discourage the use of file locking by applications.
The NFS version 4 protocol provides more aggressive caching
strategies with the following design goals:
...
...
o Provide the same caching benefits as previous versions of the NFS
protocol when unable to provide the more aggressive model.
...
... delegation. This process of handling delegation reclaim reconciles
three principles of the NFS version 4 protocol:
...
... client.
Share reservations and record locks are the facilities the NFS
version 4 protocol provides to allow applications to coordinate
...
... 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
...
...
In order to avoid invalidating the sharing assumptions that
applications rely on, NFS version 4 clients should not provide cached
...
... Delegation") two additional rules apply. Note that these rules are
obeyed in practice by many NFS version 2 and version 3 clients ...
... choose to do the revalidation more often (i.e., at OPENs
specifying DENY=NONE) to parallel the NFS version 3 protocol's
practice for the benefit of users assuming this degree of cache ...
... as all applications manipulating the file obey this convention, they
will work on a local filesystem. However, they may not work with the
NFS version 4 protocol unless clients refrain from data caching.
...
... cache data, the file data needs to be organized
according to the filesystem object to which the data belongs. For
NFS version 3 clients, the typical practice has been to assume for
...
... cache on this basis.
In the NFS version 4 protocol, there is now the possibility to have
significant deviations from a "one filehandle per object" model
...
...
By providing a method to differentiate filehandles, the NFS version 4
protocol alleviates a potential functional regression in comparison ...
... protocol alleviates a potential functional regression in comparison
with the NFS version 3 protocol. Without this method, caching
...
... 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
on multiple clients ...
... clients but that is not the issue being addressed here.
For the purposes of data caching, the following steps allow an NFS
version 4 client ...
... The server also has a dilemma in that the client that fails to
respond to the recall might also be sending other NFS requests,
including those that renew the lease before the lease expires.
Without returning an error for those lease renewing operations, the
...
... environment where the potential incoherences mentioned above can be
reasonably managed. These rules are derived from the practice of
previous NFS protocols.
o All attributes for a given file (per-fsid attributes excepted) are
...
... In some operating environments, the equivalent to time_access is
expected to be implicitly updated by each read of the content of the
file object. If an NFS client is caching the content of a file
object, whether it is a regular file, directory, or symbolic link ...
... client will not see an updated time_access
attribute. However, in many operating environments, neither will
any process running on the server. Thus NFS clients are at no
disadvantage with respect to local processes.
...
... To address the requirement of an NFS protocol that can evolve as the
need arises, the NFS version 4 ...
... requirement of an NFS protocol that can evolve as the
need arises, the NFS version 4 protocol contains the rules and
framework ...
... documented in a standards track RFC. Therefore, each minor version
number will correspond to an RFC. Minor version zero of the NFS
version 4 protocol is represented by this RFC. The COMPOUND
...
... client, it means
that the operation should not be sent to the server. For the
server, an NFS error can be returned as opposed to "dropping"
the request as an XDR decode error. This approach allows for
...
... processing options." The remainder of this Internationalization
section defines the NFS version 4 stringprep profiles ...
...
There are three UTF-8 string types defined for NFS version 4:
utf8str_cs, utf8str_cis, and utf8str_mixed. Separate profiles ...
... The utf8str_cs type is a case sensitive string of 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
...
... processing via the utf8str_cs profile. If the strings are two names
inside a directory, the NFS version 4 server will need to either:
...
... primarily for dealing with 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 ...
... NFS version 4 file server supports the case_insensitive
filesystem attribute, and if case_insensitive is true, the NFS
version 4 server MUST use Table B.2 (in addition to Table B1) when
...
... 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
...
...
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
...
... The utf8str_cis type is a case insensitive string of UTF-8
characters. Its primary use in NFS Version 4 is for naming NFS
...
... suffix that
is fully qualified domain name. Its primary use in NFS Version 4 is
for naming principals ...
...
NFS error numbers are assigned to failed operations within a compound
request. A compound request contains a number of NFS operations that
...
... NFS error numbers are assigned to failed operations within a compound
request. A compound request contains a number of NFS operations that
have their results encoded in sequence in a compound reply. The
results of successful operations will consist of an NFS4_OK status
...
... have their results encoded in sequence in a compound reply. The
results of successful operations will consist of an NFS4_OK status
followed by the encoded results of the operation. If an NFS
operation fails, an error status will be entered in the reply and the
...
... cookie is stale.
NFS4ERR_BADHANDLE Illegal NFS filehandle. The filehandle failed
internal consistency checks.
...
...
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 ...
... encapsulated within the COMPOUND procedure. This requires that the
client combine one or more of the NFS version 4 operations into a
single request.
...
... client
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 ...
... 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
CB_COMPOUND request also encapsulates the remaining operations of the
...
... DESCRIPTION
The COMPOUND procedure is used to combine one or more of the NFS
operations into a single RPC request. The main NFS ...
... NFS
operations into a single RPC request. The main NFS RPC program has
two main procedures: NULL and COMPOUND. All other operations use the
...
... reliably perform an access check with only current file attributes.
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
...
... 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 version 4
protocol, the client ...
... clients.
Servers that limit NFS access to "shares" or "exported" filesystems
should provide a pseudo-filesystem into which the exported
...
... versions of the protocol assigned special semantics to
the names "." and "..". NFS version 4 assigns no special semantics
...
... switch (limit_by4 limitby) {
/* limit specified as file size */
case NFS_LIMIT_SIZE:
uint64_t filesize;
...
... uint64_t filesize;
/* limit specified by number of blocks */
case NFS_LIMIT_BLOCKS:
nfs_modified_limit4 mod_blocks;
} ;
...
... The OPEN operation contains support for EXCLUSIVE create. The
mechanism is similar to the support in NFS version 3 [RFC1813]. As
...
... version 3 [RFC1813]. As
in NFS version 3, this mechanism provides reliable exclusive
creation. Exclusive create ...
... framework. If the requester is not
authorized to READ or WRITE (depending on the share_access value),
the server must return NFS4ERR_ACCESS. Note that since the NFS
version 4 protocol does not impose any requirement ...
... client will periodically either dispose of its
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
...
... IMPLEMENTATION
Commonly used as the first operator in an NFS request to set the
context for following operations.
...
... [RFC2055], [RFC2224]. The intent for NFS version 4 is that the
public filehandle (represented by the PUTPUBFH operation) be used as
...
... IMPLEMENTATION
Used as the first operator in an NFS request to set the context for
following operations.
...
... RFC2224] contains further
discussion of the functionality. With NFS version 4, that type of
specification is not directly available in the LOOKUP operation ...
... 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,
...
... client is responsible for constructing its request such that the
use of either PUTROOTFH or PUTPUBFH are used to signify absolute or
relative evaluation of an NFS URL respectively.
...
... place on that evaluation with respect to how much of its namespace
has been made available. These same warnings apply to NFS version 4.
It is likely, therefore that because of server implementation
...
... version 4.
It is likely, therefore that because of server implementation
details, an NFS version 3 absolute public filehandle lookup may
...
... version 3 absolute public filehandle lookup may
behave differently than an NFS version 4 absolute resolution.
...
... method of employing SNEGO. This
method is not available with NFS version 4 as filehandles are not
overloaded ...
... overloaded with special meaning and therefore do not provide the same
framework as NFS versions 2 and 3. Clients should therefore use the
...
... IMPLEMENTATION
Commonly used as the first operator in an NFS request to set the
context for following operations.
...
... interfaces may also be bound to the local
operating environment in a way that does not translate well into the
NFS protocol. Therefore the use of the dircount and maxcount fields
are provided to allow the client the ability to provide guidelines to
...
... Since some servers will not be returning "." and ".." entries as has
been done with previous versions of the NFS protocol, the client that
requires these entries be present in READDIR responses must fabricate
...
... opaque to the server. That is, whether
created by an NFS client or created locally on the server, the data
...
... IMPLEMENTATION
NFS versions 2 and 3 required a different operator RMDIR for
directory removal and REMOVE ...
... directory) because they knew the server would check the file type.
NFS version 4 REMOVE can be used to delete ...
... IMPLEMENTATION
The SECINFO operation is expected to be used by the NFS client when
the error value ...
... client when
the error value of NFS4ERR_WRONGSEC is returned from another NFS
operation. This signifies to the client that the server's security
policy ...
... whereby a 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
...
... guard condition and the setting of the attributes have the potential
to compromise this function, as would the corresponding delay in the
NFS version 4 emulation. Therefore, NFS version 4 ...
... NFS version 4 emulation. Therefore, NFS version 4 servers should
take care to avoid such delays, to the degree possible, when
...
... is FILE_SYNC4, the server must commit the data written plus all
filesystem metadata to stable storage before returning results. This
corresponds to the NFS version 2 protocol semantics. Any other
...
... version 4 protocol
service and must be unique between instances of the NFS version 4
protocol server ...
... verifier is defined to allow a client to detect different
instances of an NFS version 4 protocol server over which cached,
...
... sections. In the interest of clarity, the terms "client" and
"server" refer to NFS clients and servers, despite the fact that for
an individual callback RPC ...
... client was the entire machine, or at least the
source IP address of the machine. The NFS server relied on the NFS
client ...
... source IP address of the machine. The NFS server relied on the NFS
client to make the proper authentication ...
... client to make the proper authentication of the end-user. The NFS
server in turn shared its files only to specific clients, as
...
... client to the NFS server. When processing NFS responses, the client
ensured that the responses came from the same IP address ...
... network) to a principal
on an NFS server. Consideration should also be given to the
integrity and privacy ...
... integrity and privacy of NFS requests and responses. The issues of
end to end mutual authentication, integrity ...
... performance
and/or reduction of CPU utilization, users of NFS version 4
implementations may choose to not use security mechanisms ...
... customer vulnerable to
an attacker in between the NFS client and server that modifies the
RPC ...
... created for the registration of
NFS version 4 named attributes. Registration will be achieved
...
... The section "Structured Data Types" discussed the r_netid field and
the corresponding r_addr field of a clientaddr4 structure. The NFS
version 4 protocol depends on the syntax and semantics ...
... switch (limit_by4 limitby) {
/* limit specified as file size */
case NFS_LIMIT_SIZE:
uint64_t filesize;
...
... uint64_t filesize;
/* limit specified by number of blocks */
case NFS_LIMIT_BLOCKS:
nfs_modified_limit4 mod_blocks;
} ;
...
... Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623prop ...
... Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC 3010(-> 3530prop), December 2000. ...
... Juszczak, Chet, "Improving the Performance and Correctness of an NFS Server," USENIX Conference Proceedings, USENIX Association, Berkeley, CA, June 1990, pages 53-63. Describes reply cache ...
... Macklem, Rick, "Lessons Learned Tuning the 4.3BSD Reno Implementation of the NFS Protocol," Winter USENIX Conference Proceedings, USENIX Association, Berkeley, CA, January 1991. Describes performance ...
... Association, Berkeley, CA, January 1991. Describes performance work in tuning the 4.3BSD Reno NFS implementation. Describes performance improvement (reduced CPU loading) through elimination of data copies. ...
... Mogul, Jeffrey C., "A Recovery Protocol for Spritely NFS," USENIX File System Workshop Proceedings, Ann Arbor, MI, USENIX Association, Berkeley, CA ...
... File System Workshop Proceedings, Ann Arbor, MI, USENIX Association, Berkeley, CA, May 1992. Second paper on Spritely NFS proposes a lease-based scheme for recovering state of consistency protocol. ...
... Pawlowski, Brian, Ron Hixon, Mark Stein, Joseph Tumminaro, "Network Computing in the UNIX and IBM Mainframe Environment," Uniforum `89 Conf. Proc., (1989) Description of an NFS server implementation for IBM's MVS operating system. ...
... Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813 ...
... Network Filesystem," USENIX Conference Proceedings, USENIX 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. ...
... Srinivasan, V., Jeffrey C. Mogul, "Spritely NFS: Implementation and Performance of Cache Consistency ...
... Consistency Protocols", WRL Research Report 89/5, Digital Equipment Corporation Western Research Laboratory, 100 Hamilton Ave., Palo
Alto, CA, 94301, May 1989. This paper analyzes the effect of applying a Sprite-like consistency protocol applied to standard NFS. The issues of recovery in a stateful environment are covered in [Mogul]. ...