NewNfsManPage

From Linux NFS

(Difference between revisions)

Revision as of 20:56, 31 August 2007

NAME

nfs - nfs and nfs4 fstab format and options

SYNOPSIS

 /etc/fstab

TO DO

Expand the SECURITY CONSIDERATIONS section
Add a section discussing NFSROOT
Add a section discussing NFS cache coherency (ie NFS is not a cluster file system)
Add more useful examples, such as mounting /usr with ro,nolock,nocto
Add a section discussing how to mount through a firewall
Refine the discussion of various options
Add a section discussing "-o remount" -- which options don't work as expected over a remount
Add a section or two covering NFS server configuration (/etc/exports, exportfs)
we can't add nfs/nfs4 client/server startup sequence (as in the README from nfs-utils), full client/server stop sequence. These depend on the initscripts package (separate from nfs-utils), and is specific to each distribution.
Check for spelling, grammar, punctuation, style, and typography
Review with mailing list
Review with LDP

DESCRIPTION

NFS is an Internet Standard protocol invented by Sun Microsystems in the 1980s to share files between systems residing on a local area network. The Linux NFS implementation supports three versions of the NFS protocol: NFS version 2 [RFC1094], NFS version 3 [RFC1813], and NFS version 4 [RFC3350].

The /etc/fstab file describes how a system's file name hierarchy is assembled from various independent file systems, including remote NFS shares. The mount (8) command is used to attach a file system to the system's name space hierarchy at a given mount point. Each line in the fstab file describes a single file system and its mount point.

For NFS file system mounts, a line in the /etc/fstab file specifies the server name, the path name of the exported server directory to mount, the local directory that is the mount point, the type of file system that is being mounted, and a list of mount options that control the way the filesystem is mounted and how the NFS client behaves when accessing files on this mount point:

 host:pathname        /mountpoint     fstype  option,option,...

The server's hostname and the export pathname are separated by a colon, the mount options are separated by commas, and the remaining fields are separated by blanks or tabs. The server's hostname can be an unqualified hostname, a fully qualified domain name, or an IPv4 address. The fstype field contains either "nfs" for version 2 or version 3 NFS mounts, or "nfs4" for NFS version 4 mounts. The nfs' and nfs4 file system types share similar mount options, which are described below.

OPTIONS

There are four classes of mount options for nfs and nfs4 file systems.

First, there are generic mount options available to all Linux file systems, such as "ro" or "sync". See mount(8) for a description of generic mount options available for all file systems.

Second, some mount options such as "mountport" or "retry" can determine how the mount command behaves. These options might be used to mount an NFS share through a network firewall, but have no affect after the mount operation has completed.

Third, some mount options determine how the NFS client behaves during normal operation, such as "rsize" and "wsize". These may be used to tune system performance, or change the client's caching or file locking behavior.

Fourth, mount options such as "timeout" or "retrans" can control aspects of Remote Procedure Call behavior. NFS clients send requests to NFS servers via Remote Procedure Calls, or RPCs. RPCs handle per-request authentication, adjust request parameters for different byte endianness on client and server, and retransmit requests that may have been lost by the network or server.

Note that some options take the form of keyword=value while some options are boolean, taking either the form of keyword or nokeyword. All options which do not use the keyword=value form use the boolean form, except for hard/soft, udp/tcp, and fg/bg.

Valid options for either the nfs or nfs4 file system type

soft \| hard	Determines the recovery behavior of the RPC client after an RPC request times out. If neither option is specified, or if the hard option is specified, the RPC is retried indefinitely. If the soft option is specified, then the RPC client fails the RPC request after a major timeout occurs, and causes the NFS client to return an error to the calling application.
timeo=n	The value, in tenths of a second, before timing out an RPC request. The default value is 600 (60 seconds) for NFS over TCP. On a UDP transport, the Linux RPC client uses an adaptive algorithm to estimate the time out value for frequently used request types such as READ and WRITE, and uses the timeo= setting for infrequently used requests such as FSINFO. The timeo= value defaults to 7 tenths of a second for NFS over UDP. After each timeout, the RPC client may retransmit the timed out request, or it may take some other action depending on the settings of the hard or retrans= options.
retrans=n	The number of RPC timeouts that must occur before a major timeout occurs. The default is 3 timeouts. If the file system is mounted with the hard option, the RPC client will generate a "server not responding" message after a major timeout, then continue to retransmit the request. If the file system is mounted with the soft option, the RPC client will abandon the request after a major timeout, and cause NFS to return an error to the application.
rsize=n	The maximum number of bytes in each network READ request that the NFS client can use when reading data from a file on an NFS server; the actual data payload size of each NFS READ request is equal to or smaller than the rsize value. The rsize value is a positive integral multiple of 1024, and the largest value supported by the Linux NFS client is 1,048,576 bytes. Specified values outside of this range are rounded down to the closest multiple of 1024, and specified values smaller than 1024 are replaced with a default of 4096. If an rsize value is not specified, or if a value is specified but is larger than the maximums either the client or server support, the client and server negotiate the largest rsize value that both will support. The rsize option as specified on the mount(8) command line appears in the /etc/mtab file, but the effective rsize value negotiated by the client and server is reported in the /proc/mounts file.
wsize=n	The maximum number of bytes per network WRITE request that the NFS client can use when writing data to a file on an NFS server. See the description of the rsize option for more details.
acregmin=n	The minimum time in seconds that the NFS client caches attributes of a regular file before it requests fresh attribute information from a server. The default is 3 seconds.
acregmax=n	The maximum time in seconds that the NFS client caches attributes of a regular file before it requests fresh attribute information from a server. The default is 60 seconds.
acdirmin=n	The minimum time in seconds that the NFS client caches attributes of a directory before it requests fresh attribute information from a server. The default is 30 seconds.
acdirmax=n	The maximum time in seconds that the NFS client caches attributes of a directory before it requests fresh attribute information from a server. The default is 60 seconds.
actimeo=n	Using actimeo sets all of acregmin, acregmax, acdirmin, and acdirmax to the same value. There is no default value.
noac	Disable attribute caching, and force synchronous writes. The noac option is synonymous with using actimeo=0,sync. If this option is not specified, the default behavior is ac. Using the noac option provides much greater cache coherency among NFS clients accessing the same files, but it extracts a significant performance penalty. Judicious use of file locking is encouraged instead.
bg \| fg	This mount option determines how the mount(8) command behaves if an attempt to mount a remote share fails. The fg option causes mount(8) to exit with an error status if any part of the mount request times out or fails outright. This is called a "foreground" mount, and is the default behavior if neither fg nor bg is specified. If the bg option is specified, a timeout or failure causes the mount(8) command to fork a child which continues to attempt to mount the remote share. The parent immediately returns with a zero exit code. This is known as a "background" mount. If the local mount point directory is missing, the mount(8) command treats that as if the mount request timed out. This permits nested NFS mounts specified in /etc/fstab to proceed in any order during system initialization.
retry=n	The number of minutes to retry an NFS mount operation in the foreground or background before giving up. The default value for foreground mounts is 2 minutes. The default value for background mounts is 10000 minutes, which is roughly one week.
sec=mode	The RPCGSS security flavor to use for accessing files on this mount point. If the sec= option is not specified, or if sec=sys is specified, the RPC client uses the AUTH_SYS security flavor for all RPC operations on this mount point. Valid security flavors are none, sys, krb5, krb5i, krb5p, lkey, lkeyi, lkeyp, spkm, spkmi, and spkmp. See the SECURITY CONSIDERATIONS section for details.
sharecache	Determines how the client's data cache is shared between mount points that mount the same remote share. If the option is not specified, or the sharecache option is specified, then all mounts of the same remote share on a client use the same data cache. If the nosharecache option is specified, then files under that mount point are cached separately from files under other mount points that may be accessing the same remote share. As of kernel 2.6.18, this is legacy caching behavior, and is considered a data risk since multiple cached copies of the same file on the same client can become out of sync following an update of one of the copies.

Valid options for the nfs file system type

proto=netid	The transport protocol used by the RPC client to transmit requests to the NFS server for this mount point. The value of netid can be either udp or tcp. Each transport protocol uses different default retrans and timeo settings; see the description of these two mount options for details. NB: This mount option controls both how the mount(8) command communicates with the portmapper and the MNT and NFS server, and what transport protocol the in-kernel NFS client uses to transmit requests to the NFS server. Specifying proto=tcp forces all traffic from the mount command and the NFS client to use TCP. Specifying proto=udp forces all traffic types to use UDP. If the proto= mount option is not specified, the mount(8) command chooses the best transport for each type of request (GETPORT, MNT, and NFS), and by default the in-kernel NFS client uses the TCP protocol. If the server doesn't support one or the other protocol, the mount(8) command attempts to discover which protocol is supported and use that one.
udp	The udp option is an alternative to proto=udp and is included for compatibility with other operating systems.
tcp	The tcp option is an alternative to proto=tcp and is included for compatibility with other operating systems.
port=n	The numeric value of the port used by the remote NFS service. If the port= option is not specified, or if the specified port value is 0, then the NFS client uses the NFS service port provided by the remote portmapper service. If any other value is specified, then the NFS client uses that value as the destination port when connecting to the remote NFS service. If the remote host's NFS service is not registered with its portmapper, or if the NFS service is not available on the specified port, the mount fails.
namlen=n	The maximum filename length on this mount. If this option is not specified, the maximum length is negotiated with the server and is usually 255 characters. Some early versions of NFS did not support this negotiation. This option can be used to ensure that pathconf(3) reports the proper maximum to applications in this circumstance.
mountport=n	The numeric value of the server's mountd port. If not specified, the client discovers the port by contacting the server's rpcbind daemon. This option can be used when mounting an NFS server through a firewall that denies access to RPC portmapper requests.
mounthost=name	The name of the host running mountd.
mountprog=n	Use an alternate RPC program number to contact the mount daemon on the remote host. This option is useful for hosts that can run multiple NFS servers. The default value is 100005 which is the standard RPC mount daemon program number.
mountvers=n	Use an alternate RPC version number to contact the mount daemon on the remote host. This option is useful for hosts that can run multiple NFS servers. The default value depends on which kernel you are using.
nfsprog=n	Use an alternate RPC program number to contact the NFS daemon on the remote host. This option is useful for hosts that can run multiple NFS servers. The default value is 100003 which is the standard RPC NFS daemon program number.
nfsvers=n	Use an alternate RPC version number to contact the NFS daemon on the remote host. This option is useful for hosts that can run multiple NFS servers. The default value depends on which kernel you are using.
vers=n	vers= is an alternative to nfsvers and is included for compatibility with other operating systems.
nolock	Disable NFS locking and do not start lockd. This is appropriate for mounting the root filesystem or /usr or /var. These filesystems are typically either read-only or not shared, and in those cases, remote locking is not needed. This also needs to be used with some old NFS servers that don't support locking. Note that applications can still get locks on files, but the locks only provide exclusion locally. Other clients mounting the same filesystem will not be able to detect the locks.
intr	Allow or do not allow signals to interrupt file operations on this mount point. When an NFS operation is interrupted, the system returns EINTR. If the intr option is not specified, signals do not interrupt NFS file operations (nointr is default). Using the intr option is preferred to using the soft option because it is significantly less likely to result in data corruption.
posix	Mount the NFS filesystem using POSIX semantics. This allows an NFS filesystem to properly support the POSIX pathconf command by querying the mount server for the maximum length of a filename. To do this, the remote host must support version two of the RPC mount protocol. Many NFS servers support only version one.
cto	Use close-to-open cache coherency semantics. If this option is not specified, the default is to use close-to-open cache coherency semantics. Using the nocto option may improve performance for read-only mounts if the data on the server changes only occasionally.
noacl	Disables Access Control List (ACL) processing.
nordirplus	Disables NFSv3 READDIRPLUS RPCs. Use this option when mounting servers that don't support or have broken READDIRPLUS implementations.

Valid options for the nfs4 file system type

proto=netid	The transport protocol used by the RPC client to transmit requests to the NFS server. The value of netid can be either udp or tcp. All NFS version 4 servers are required to support TCP, so the default transport protocol for NFS version 4 is TCP.
port=n	The numeric value of the port used by the remote NFS service. If the port= option is not specified, the NFS client uses the standard NFS port number of 2049 without checking the remote portmapper service. If the specified port value is 0, then the NFS client uses the NFS service port provided by the remote portmapper service. If any other value is specified, then the NFS client uses that value as the destination port when connecting to the remote NFS service. If the remote host's NFS service is not registered with its portmapper, or if the NFS service is not available on the specified port, the mount fails.
intr	Allow or do not allow signals to interrupt file operations on this mount point. When an NFS operation is interrupted, the system returns EINTR. If the intr option is not specified, signals can interrupt NFS file operations (intr is default). Using the intr option is preferred to using the soft option because it is significantly less likely to result in data corruption.
clientaddr=n.n.n.n	Specifies a single IPv4 address in dotted-quad form that the NFS client advertises to allow servers to perform NFSv4 callback requests against files on this mount point. If the server is not able to establish callback connections to clients, performance may degrade, or accesses to files may temporarily hang. If this option is not specified, the mount(8) command attempts to discover an appropriate callback address automatically. The automatic discovery process is not perfect, however. In the presence of multiple client network interfaces, special routing policies, or atypical network topologies, the exact address to use for callbacks may be nontrivial to determine.

SECURITY CONSIDERATIONS

NFS provides access control for data, but depends on its RPC implementation to provide authentication of NFS requests. Traditional NFS access control mimics the standard mode bit access control provided in local file systems. Traditional RPC authentication uses a number to represent each user (usually the user's own uid), a number to represent the user's group (the user's gid), and a set of up to 16 auxiliary group numbers to represent other groups of which the user may be a member. File data and user ID values appear in the clear on the network.

Moreover, NFS versions 2 and 3 use separate protocols for mounting, for locking and unlocking files, and for reporting system status of clients and servers. These auxiliary protocols use no authentication.

In addition to combining all the auxiliary protocols into a single protocol, NFS version 4 introduces more advanced forms of access control, authentication, and in-transit data protection. Linux also implements the proprietary NFSv3 access control list implementation built into Solaris, but never standardized, and allows the use of advanced authentication modes for NFS version 2 and version 3 mounts.

The NFS version 4 specification mandates NFSv4 ACLs, RPCGSS authentication, and RPCGSS security flavors that provide per-RPC integrity checking and encryption, and it applies to all NFS version 4 operations including mounting, file locking, and so on. Note that Linux does not yet implement security mode negotiation between NFS version 4 clients and servers.

A mount option enables the RPCGSS security mode that is in effect on a given NFS mount point. Using the sec=krb5 mount option provides a cryptographic proof of a user's identity in each RPC request that passes between client and server. This makes a very strong guarantee about who is accessing what data on the server.

Two other flavors of Kerberos security are supported as well. krb5i provides a cryptographically strong guarantee that the data in each RPC request has not been tampered with. And krbp encrypts every RPC request so the data is not exposed at all during transit on networks between NFS client and server. There can be some performance impact when using integrity checking or encryption, however.

Support for other forms of cryptographic security are also available, including lipkey and SPKM3.

EXAMPLES

To mount a remote share using NFS version 2, use the nfs file system type and specify the nfsvers=2 mount option. To mount using NFS version 3, use the nfs file system type and specify the nfsvers=3 mount option. To mount using NFS version 4, use the nfs4 file system type (the nfsvers mount option is not supported for the nfs4 file system type).

Here is an example from an /etc/fstab file for an NFS version 3 mount over TCP.

 server:/export/share    /mnt            nfs             nfsvers=3,proto=tcp

Here is an example for an NFS version 4 mount over TCP using Kerberos 5 mutual authentication.

 server:/export/share    /mnt            nfs4            sec=krb5

FILES

/etc/fstab file system table

@@ Line 136: / Line 136: @@
 |The transport protocol used by the RPC client to transmit requests to the NFS server for this mount point. The value of ''netid'' can be either '''udp''' or '''tcp'''. Each transport protocol uses different default ''retrans'' and ''timeo'' settings; see the description of these two mount options for details.
 ''NB:'' This mount option controls both how the '''mount'''(8) command communicates with the portmapper and the MNT and NFS server, and what transport protocol the in-kernel NFS client uses to transmit requests to the NFS server. Specifying ''proto=tcp'' forces all traffic from the mount command and the NFS client to use TCP. Specifying ''proto=udp'' forces all traffic types to use UDP. If the ''proto='' mount option is not specified, the '''mount'''(8) command chooses the best transport for each type of request (GETPORT, MNT, and NFS), and by default the in-kernel NFS client uses the TCP protocol. If the server doesn't support one or the other protocol, the '''mount'''(8) command attempts to discover which protocol is supported and use that one.
+|-
+|valign="top"|udp
+|The ''udp'' option is an alternative to ''proto=udp'' and is included for compatibility with other operating systems.
+|-
+|valign="top"|tcp
+|The ''tcp'' option is an alternative to ''proto=tcp'' and is included for compatibility with other operating systems.
 |-
 |valign="top"|port=''n''
@@ Line 162: / Line 168: @@
 |-
 |valign="top"|vers=''n''
-|''vers='' is an alternative to ''nfsvers'' and is compatible with many other operating systems.
+|''vers='' is an alternative to ''nfsvers'' and is included for compatibility with other operating systems.
 |-
 |valign="top"|nolock

NewNfsManPage

From Linux NFS

Revision as of 20:56, 31 August 2007

Contents

NAME

SYNOPSIS

TO DO

DESCRIPTION

OPTIONS

Valid options for either the nfs or nfs4 file system type

Valid options for the nfs file system type

Valid options for the nfs4 file system type

SECURITY CONSIDERATIONS

EXAMPLES

FILES

SEE ALSO

Views

Personal tools

Navigation

Search

Toolbox