+.B udp
+The
+.B udp
+option is an alternative to specifying
+.BR proto=udp.
+It is included for compatibility with other operating systems.
+.TP 1.5i
+.B tcp
+The
+.B tcp
+option is an alternative to specifying
+.BR proto=tcp.
+It is included for compatibility with other operating systems.
+.TP 1.5i
+.BI port= n
+The numeric value of the server's NFS service port.
+If the server's NFS service is not available on the specified port,
+the mount request fails.
+.IP
+If this option is not specified, or if the specified port value is 0,
+then the NFS client uses the NFS service port number
+advertised by the server's rpcbind service.
+The mount request fails if the server's rpcbind service is not available,
+the server's NFS service is not registered with its rpcbind service,
+or the server's NFS service is not available on the advertised port.
+.TP 1.5i
+.BI mountport= n
+The numeric value of the server's mountd port.
+If the server's mountd service is not available on the specified port,
+the mount request fails.
+.IP
+If this option is not specified,
+or if the specified port value is 0, then the
+.BR mount (8)
+command uses the mountd service port number
+advertised by the server's rpcbind service.
+The mount request fails if the server's rpcbind service is not available,
+the server's mountd service is not registered with its rpcbind service,
+or the server's mountd service is not available on the advertised port.
+.IP
+This option can be used when mounting an NFS server
+through a firewall that blocks the rpcbind protocol.
+.TP 1.5i
+.BI mountproto= netid
+The transport protocol name and protocol family the NFS client uses
+to transmit requests to the NFS server's mountd service when performing
+this mount request, and when later unmounting this mount point.
+.IP
+If support for TI-RPC is built into the
+.B mount.nfs
+command,
+.I netid
+is a valid netid listed in
+.IR /etc/netconfig .
+Otherwise,
+.I netid
+is one of "tcp" or "udp," and only IPv4 may be used.
+.IP
+This option can be used when mounting an NFS server
+through a firewall that blocks a particular transport.
+When used in combination with the
+.B proto
+option, different transports for mountd requests and NFS requests
+can be specified.
+If the server's mountd service is not available via the specified
+transport, the mount request fails.
+.IP
+Refer to the TRANSPORT METHODS section for more on how the
+.B mountproto
+mount option interacts with the
+.B proto
+mount option.
+.TP 1.5i
+.BI mounthost= name
+The hostname of the host running mountd.
+If this option is not specified, the
+.BR mount (8)
+command assumes that the mountd service runs
+on the same host as the NFS service.
+.TP 1.5i
+.BI mountvers= n
+The RPC version number used to contact the server's mountd.
+If this option is not specified, the client uses a version number
+appropriate to the requested NFS version.
+This option is useful when multiple NFS services
+are running on the same remote server host.
+.TP 1.5i
+.BI namlen= n
+The maximum length of a pathname component on this mount.
+If this option is not specified, the maximum length is negotiated
+with the server. In most cases, this maximum length is 255 characters.
+.IP
+Some early versions of NFS did not support this negotiation.
+Using this option ensures that
+.BR pathconf (3)
+reports the proper maximum component length to applications
+in such cases.
+.TP 1.5i
+.BI nfsvers= n
+The NFS protocol version number used to contact the server's NFS service.
+If the server does not support the requested version, the mount request fails.
+If this option is not specified, the client negociate a suitable version with
+the server, trying version 4 first, version 3 second, and version 2 last.
+.TP 1.5i
+.BI vers= n
+This option is an alternative to the
+.B nfsvers
+option.
+It is included for compatibility with other operating systems.
+.TP 1.5i
+.BR lock " / " nolock
+Selects whether to use the NLM sideband protocol to lock files on the server.
+If neither option is specified (or if
+.B lock
+is specified), NLM locking is used for this mount point.
+When using the
+.B nolock
+option, applications can lock files,
+but such locks provide exclusion only against other applications
+running on the same client.
+Remote applications are not affected by these locks.
+.IP
+NLM locking must be disabled with the
+.B nolock
+option when using NFS to mount
+.I /var
+because
+.I /var
+contains files used by the NLM implementation on Linux.
+Using the
+.B nolock
+option is also required when mounting exports on NFS servers
+that do not support the NLM protocol.
+.TP 1.5i
+.BR intr " / " nointr
+Selects whether to allow signals to interrupt file operations
+on this mount point. If neither option
+is specified (or if
+.B nointr
+is specified),
+signals do not interrupt NFS file operations. If
+.B intr
+is specified, system calls return EINTR if an in-progress NFS operation is interrupted by
+a signal.
+.IP
+Using the
+.B intr
+option is preferred to using the
+.B soft
+option because it is significantly less likely to result in data corruption.
+.IP
+The
+.BR intr " / " nointr
+mount option is deprecated after kernel 2.6.25.
+Only SIGKILL can interrupt a pending NFS operation on these kernels,
+and if specified, this mount option is ignored to provide backwards
+compatibility with older kernels.
+.TP 1.5i
+.BR cto " / " nocto
+Selects whether to use close-to-open cache coherence semantics.
+If neither option is specified (or if
+.B cto
+is specified), the client uses close-to-open
+cache coherence semantics. If the
+.B nocto
+option is specified, the client uses a non-standard heuristic to determine when
+files on the server have changed.
+.IP
+Using the
+.B nocto
+option may improve performance for read-only mounts,
+but should be used only if the data on the server changes only occasionally.
+The DATA AND METADATA COHERENCE section discusses the behavior
+of this option in more detail.
+.TP 1.5i
+.BR acl " / " noacl
+Selects whether to use the NFSACL sideband protocol on this mount point.
+The NFSACL sideband protocol is a proprietary protocol
+implemented in Solaris that manages Access Control Lists. NFSACL was never
+made a standard part of the NFS protocol specification.
+.IP
+If neither
+.B acl
+nor
+.B noacl
+option is specified,
+the NFS client negotiates with the server
+to see if the NFSACL protocol is supported,
+and uses it if the server supports it.
+Disabling the NFSACL sideband protocol may be necessary
+if the negotiation causes problems on the client or server.
+Refer to the SECURITY CONSIDERATIONS section for more details.
+.TP 1.5i
+.BR rdirplus " / " nordirplus
+Selects whether to use NFS version 3 READDIRPLUS requests.
+If this option is not specified, the NFS client uses READDIRPLUS requests
+on NFS version 3 mounts to read small directories.
+Some applications perform better if the client uses only READDIR requests
+for all directories.
+.SS "Valid options for the nfs4 file system type"
+Use these options, along with the options in the first subsection above,
+for mounting the
+.B nfs4
+file system type.
+.TP 1.5i
+.BI proto= netid
+The transport protocol name and protocol family the NFS client uses
+to transmit requests to the NFS server for this mount point.
+If an NFS server has both an IPv4 and an IPv6 address, using a specific
+netid will force the use of IPv4 or IPv6 networking to communicate
+with that server.
+.IP
+If support for TI-RPC is built into the
+.B mount.nfs
+command,
+.I netid
+is a valid netid listed in
+.IR /etc/netconfig .
+Otherwise,
+.I netid
+is one of "tcp" or "udp," and only IPv4 may be used.
+.IP
+All NFS version 4 servers are required to support TCP,
+so if this mount option is not specified, the NFS version 4 client
+uses the TCP protocol.
+Refer to the TRANSPORT METHODS section for more details.
+.TP 1.5i
+.BI port= n
+The numeric value of the server's NFS service port.
+If the server's NFS service is not available on the specified port,
+the mount request fails.
+.IP
+If this mount option is not specified,
+the NFS client uses the standard NFS port number of 2049
+without first checking the server's rpcbind service.
+This allows an NFS version 4 client to contact an NFS version 4
+server through a firewall that may block rpcbind requests.
+.IP
+If the specified port value is 0,
+then the NFS client uses the NFS service port number
+advertised by the server's rpcbind service.
+The mount request fails if the server's rpcbind service is not available,
+the server's NFS service is not registered with its rpcbind service,
+or the server's NFS service is not available on the advertised port.
+.TP 1.5i
+.BR intr " / " nointr
+Selects whether to allow signals to interrupt file operations
+on this mount point. If neither option is specified (or if
+.B intr
+is specified), system calls return EINTR if an in-progress NFS operation
+is interrupted by a signal. If
+.B nointr
+is specified, signals do not
+interrupt NFS operations.
+.IP
+Using the
+.B intr
+option is preferred to using the
+.B soft
+option because it is significantly less likely to result in data corruption.
+.IP
+The
+.BR intr " / " nointr
+mount option is deprecated after kernel 2.6.25.
+Only SIGKILL can interrupt a pending NFS operation on these kernels,
+and if specified, this mount option is ignored to provide backwards
+compatibility with older kernels.
+.TP 1.5i
+.BR cto " / " nocto
+Selects whether to use close-to-open cache coherence semantics
+for NFS directories on this mount point.
+If neither
+.B cto
+nor
+.B nocto
+is specified,
+the default is to use close-to-open cache coherence
+semantics for directories.
+.IP
+File data caching behavior is not affected by this option.
+The DATA AND METADATA COHERENCE section discusses
+the behavior of this option in more detail.
+.TP 1.5i
+.BI clientaddr= n.n.n.n
+Specifies a single IPv4 address (in dotted-quad form),
+or a non-link-local IPv6 address,
+that the NFS client advertises to allow servers
+to perform NFS version 4 callback requests against
+files on this mount point. If the server is unable to
+establish callback connections to clients, performance
+may degrade, or accesses to files may temporarily hang.
+.IP
+If this option is not specified, the
+.BR 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.
+.SH MOUNT CONFIGURATION FILE
+If the mount command is configured to do so, all of the mount options
+described in the previous section can also be configured in the
+.I /etc/nfsmount.conf
+file. See
+.BR nfsmount.conf(5)
+for details.
+.SH EXAMPLES
+To mount an export using NFS version 2,
+use the
+.B nfs
+file system type and specify the
+.B nfsvers=2
+mount option.
+To mount using NFS version 3,
+use the
+.B nfs
+file system type and specify the
+.B nfsvers=3
+mount option.
+To mount using NFS version 4,
+use the
+.B nfs4
+file system type.
+The
+.B nfsvers
+mount option is not supported for the
+.B nfs4
+file system type.
+.P
+The following example from an
+.I /etc/fstab
+file causes the mount command to negotiate
+reasonable defaults for NFS behavior.
+.P
+.NF
+.TA 2.5i +0.7i +0.7i +.7i
+ server:/export /mnt nfs defaults 0 0
+.FI
+.P
+Here is an example from an /etc/fstab file for an NFS version 2 mount over UDP.
+.P
+.NF
+.TA 2.5i +0.7i +0.7i +.7i
+ server:/export /mnt nfs nfsvers=2,proto=udp 0 0
+.FI
+.P
+Try this example to mount using NFS version 4 over TCP
+with Kerberos 5 mutual authentication.
+.P
+.NF
+.TA 2.5i +0.7i +0.7i +.7i
+ server:/export /mnt nfs4 sec=krb5 0 0
+.FI
+.P
+This example can be used to mount /usr over NFS.
+.P
+.NF
+.TA 2.5i +0.7i +0.7i +.7i
+ server:/export /usr nfs ro,nolock,nocto,actimeo=3600 0 0
+.FI
+.P
+This example shows how to mount an NFS server
+using a raw IPv6 link-local address.
+.P
+.NF
+.TA 2.5i +0.7i +0.7i +.7i
+ [fe80::215:c5ff:fb3e:e2b1%eth0]:/export /mnt nfs defaults 0 0
+.FI
+.SH "TRANSPORT METHODS"
+NFS clients send requests to NFS servers via
+Remote Procedure Calls, or
+.IR RPCs .
+The RPC client discovers remote service endpoints automatically,
+handles per-request authentication,
+adjusts request parameters for different byte endianness on client and server,
+and retransmits requests that may have been lost by the network or server.
+RPC requests and replies flow over a network transport.
+.P
+In most cases, the
+.BR mount (8)
+command, NFS client, and NFS server
+can automatically negotiate proper transport
+and data transfer size settings for a mount point.
+In some cases, however, it pays to specify
+these settings explicitly using mount options.
+.P
+Traditionally, NFS clients used the UDP transport exclusively for
+transmitting requests to servers. Though its implementation is
+simple, NFS over UDP has many limitations that prevent smooth
+operation and good performance in some common deployment
+environments. Even an insignificant packet loss rate results in the
+loss of whole NFS requests; as such, retransmit timeouts are usually
+in the subsecond range to allow clients to recover quickly from
+dropped requests, but this can result in extraneous network traffic
+and server load.
+.P
+However, UDP can be quite effective in specialized settings where
+the networks MTU is large relative to NFSs data transfer size (such
+as network environments that enable jumbo Ethernet frames). In such
+environments, trimming the
+.B rsize
+and
+.B wsize
+settings so that each
+NFS read or write request fits in just a few network frames (or even
+in a single frame) is advised. This reduces the probability that
+the loss of a single MTU-sized network frame results in the loss of
+an entire large read or write request.
+.P
+TCP is the default transport protocol used for all modern NFS
+implementations. It performs well in almost every conceivable
+network environment and provides excellent guarantees against data
+corruption caused by network unreliability. TCP is often a
+requirement for mounting a server through a network firewall.
+.P
+Under normal circumstances, networks drop packets much more
+frequently than NFS servers drop requests. As such, an aggressive
+retransmit timeout setting for NFS over TCP is unnecessary. Typical
+timeout settings for NFS over TCP are between one and ten minutes.
+After the client exhausts its retransmits (the value of the
+.B retrans
+mount option), it assumes a network partition has occurred,
+and attempts to reconnect to the server on a fresh socket. Since
+TCP itself makes network data transfer reliable,
+.B rsize
+and
+.B wsize
+can safely be allowed to default to the largest values supported by
+both client and server, independent of the network's MTU size.
+.SS "Using the mountproto mount option"
+This section applies only to NFS version 2 and version 3 mounts
+since NFS version 4 does not use a separate protocol for mount
+requests.
+.P
+The Linux NFS client can use a different transport for
+contacting an NFS server's rpcbind service, its mountd service,
+its Network Lock Manager (NLM) service, and its NFS service.
+The exact transports employed by the Linux NFS client for
+each mount point depends on the settings of the transport
+mount options, which include
+.BR proto ,
+.BR mountproto ,
+.BR udp ", and " tcp .
+.P
+The client sends Network Status Manager (NSM) notifications
+via UDP no matter what transport options are specified, but
+listens for server NSM notifications on both UDP and TCP.
+The NFS Access Control List (NFSACL) protocol shares the same
+transport as the main NFS service.
+.P
+If no transport options are specified, the Linux NFS client
+uses UDP to contact the server's mountd service, and TCP to
+contact its NLM and NFS services by default.
+.P
+If the server does not support these transports for these services, the
+.BR mount (8)
+command attempts to discover what the server supports, and then retries
+the mount request once using the discovered transports.
+If the server does not advertise any transport supported by the client
+or is misconfigured, the mount request fails.
+If the
+.B bg
+option is in effect, the mount command backgrounds itself and continues
+to attempt the specified mount request.
+.P
+When the
+.B proto
+option, the
+.B udp
+option, or the
+.B tcp
+option is specified but the
+.B mountproto
+option is not, the specified transport is used to contact
+both the server's mountd service and for the NLM and NFS services.
+.P
+If the
+.B mountproto
+option is specified but none of the
+.BR proto ", " udp " or " tcp
+options are specified, then the specified transport is used for the
+initial mountd request, but the mount command attempts to discover
+what the server supports for the NFS protocol, preferring TCP if
+both transports are supported.
+.P
+If both the
+.BR mountproto " and " proto
+(or
+.BR udp " or " tcp )
+options are specified, then the transport specified by the
+.B mountproto
+option is used for the initial mountd request, and the transport
+specified by the
+.B proto
+option (or the
+.BR udp " or " tcp " options)"
+is used for NFS, no matter what order these options appear.
+No automatic service discovery is performed if these options are
+specified.
+.P
+If any of the
+.BR proto ", " udp ", " tcp ", "
+or
+.B mountproto
+options are specified more than once on the same mount command line,
+then the value of the rightmost instance of each of these options
+takes effect.
+.SH "DATA AND METADATA COHERENCE"
+Some modern cluster file systems provide
+perfect cache coherence among their clients.
+Perfect cache coherence among disparate NFS clients
+is expensive to achieve, especially on wide area networks.
+As such, NFS settles for weaker cache coherence that
+satisfies the requirements of most file sharing types. Normally,
+file sharing is completely sequential:
+first client A opens a file, writes something to it, then closes it;
+then client B opens the same file, and reads the changes.
+.DT
+.SS "Close-to-open cache consistency"
+When an application opens a file stored on an NFS server,
+the NFS client checks that it still exists on the server
+and is permitted to the opener by sending a GETATTR or ACCESS request.
+When the application closes the file,
+the NFS client writes back any pending changes
+to the file so that the next opener can view the changes.
+This also gives the NFS client an opportunity to report
+any server write errors to the application
+via the return code from
+.BR close (2).
+The behavior of checking at open time and flushing at close time
+is referred to as close-to-open cache consistency.
+.SS "Weak cache consistency"
+There are still opportunities for a client's data cache
+to contain stale data.
+The NFS version 3 protocol introduced "weak cache consistency"
+(also known as WCC) which provides a way of efficiently checking
+a file's attributes before and after a single request.
+This allows a client to help identify changes
+that could have been made by other clients.
+.P
+When a client is using many concurrent operations
+that update the same file at the same time
+(for example, during asynchronous write behind),
+it is still difficult to tell whether it was
+that client's updates or some other client's updates
+that altered the file.
+.SS "Attribute caching"
+Use the
+.B noac
+mount option to achieve attribute cache coherence
+among multiple clients.
+Almost every file system operation checks
+file attribute information.
+The client keeps this information cached
+for a period of time to reduce network and server load.
+When
+.B noac
+is in effect, a client's file attribute cache is disabled,
+so each operation that needs to check a file's attributes
+is forced to go back to the server.
+This permits a client to see changes to a file very quickly,
+at the cost of many extra network operations.
+.P
+Be careful not to confuse the
+.B noac
+option with "no data caching."
+The
+.B noac
+mount option prevents the client from caching file metadata,
+but there are still races that may result in data cache incoherence
+between client and server.
+.P
+The NFS protocol is not designed to support
+true cluster file system cache coherence
+without some type of application serialization.
+If absolute cache coherence among clients is required,
+applications should use file locking. Alternatively, applications
+can also open their files with the O_DIRECT flag
+to disable data caching entirely.
+.SS "Directory entry caching"
+The Linux NFS client caches the result of all NFS LOOKUP requests.
+If the requested directory entry exists on the server,
+the result is referred to as a
+.IR positive " lookup result.
+If the requested directory entry does not exist on the server
+(that is, the server returned ENOENT),
+the result is referred to as
+.IR negative " lookup result.
+.P
+To detect when directory entries have been added or removed
+on the server,
+the Linux NFS client watches a directory's mtime.
+If the client detects a change in a directory's mtime,
+the client drops all cached LOOKUP results for that directory.
+Since the directory's mtime is a cached attribute, it may
+take some time before a client notices it has changed.
+See the descriptions of the
+.BR acdirmin ", " acdirmax ", and " noac
+mount options for more information about
+how long a directory's mtime is cached.
+.P
+Caching directory entries improves the performance of applications that
+do not share files with applications on other clients.
+Using cached information about directories can interfere
+with applications that run concurrently on multiple clients and
+need to detect the creation or removal of files quickly, however.
+The
+.B lookupcache
+mount option allows some tuning of directory entry caching behavior.
+.P
+Before kernel release 2.6.28,
+the Linux NFS client tracked only positive lookup results.
+This permitted applications to detect new directory entries
+created by other clients quickly while still providing some of the
+performance benefits of caching.
+If an application depends on the previous lookup caching behavior
+of the Linux NFS client, you can use
+.BR lookupcache=positive .
+.P
+If the client ignores its cache and validates every application
+lookup request with the server,
+that client can immediately detect when a new directory
+entry has been either created or removed by another client.
+You can specify this behavior using
+.BR lookupcache=none .
+The extra NFS requests needed if the client does not
+cache directory entries can exact a performance penalty.
+Disabling lookup caching
+should result in less of a performance penalty than using
+.BR noac ,
+and has no effect on how the NFS client caches the attributes of files.
+.P
+.SS "The sync mount option"
+The NFS client treats the
+.B sync
+mount option differently than some other file systems
+(refer to
+.BR mount (8)
+for a description of the generic
+.B sync
+and
+.B async
+mount options).
+If neither
+.B sync
+nor
+.B async
+is specified (or if the
+.B async
+option is specified),
+the NFS client delays sending application
+writes to the server
+until any of these events occur:
+.IP
+Memory pressure forces reclamation of system memory resources.
+.IP
+An application flushes file data explicitly with
+.BR sync (2),
+.BR msync (2),
+or
+.BR fsync (3).
+.IP
+An application closes a file with
+.BR close (2).
+.IP
+The file is locked/unlocked via
+.BR fcntl (2).
+.P
+In other words, under normal circumstances,
+data written by an application may not immediately appear
+on the server that hosts the file.
+.P
+If the
+.B sync
+option is specified on a mount point,
+any system call that writes data to files on that mount point
+causes that data to be flushed to the server
+before the system call returns control to user space.
+This provides greater data cache coherence among clients,
+but at a significant performance cost.
+.P
+Applications can use the O_SYNC open flag to force application
+writes to individual files to go to the server immediately without
+the use of the
+.B sync
+mount option.
+.SS "Using file locks with NFS"
+The Network Lock Manager protocol is a separate sideband protocol
+used to manage file locks in NFS version 2 and version 3.
+To support lock recovery after a client or server reboot,
+a second sideband protocol --
+known as the Network Status Manager protocol --
+is also required.
+In NFS version 4,
+file locking is supported directly in the main NFS protocol,
+and the NLM and NSM sideband protocols are not used.
+.P
+In most cases, NLM and NSM services are started automatically,
+and no extra configuration is required.
+Configure all NFS clients with fully-qualified domain names
+to ensure that NFS servers can find clients to notify them of server reboots.
+.P
+NLM supports advisory file locks only.
+To lock NFS files, use
+.BR fcntl (2)
+with the F_GETLK and F_SETLK commands.
+The NFS client converts file locks obtained via
+.BR flock (2)
+to advisory locks.
+.P
+When mounting servers that do not support the NLM protocol,
+or when mounting an NFS server through a firewall
+that blocks the NLM service port,
+specify the
+.B nolock
+mount option. NLM locking must be disabled with the
+.B nolock
+option when using NFS to mount
+.I /var
+because
+.I /var
+contains files used by the NLM implementation on Linux.
+.P
+Specifying the
+.B nolock
+option may also be advised to improve the performance
+of a proprietary application which runs on a single client
+and uses file locks extensively.
+.SS "NFS version 4 caching features"
+The data and metadata caching behavior of NFS version 4
+clients is similar to that of earlier versions.
+However, NFS version 4 adds two features that improve
+cache behavior:
+.I change attributes
+and
+.IR "file delegation" .
+.P
+The
+.I change attribute
+is a new part of NFS file and directory metadata
+which tracks data changes.
+It replaces the use of a file's modification
+and change time stamps
+as a way for clients to validate the content
+of their caches.
+Change attributes are independent of the time stamp
+resolution on either the server or client, however.
+.P
+A
+.I file delegation
+is a contract between an NFS version 4 client
+and server that allows the client to treat a file temporarily
+as if no other client is accessing it.
+The server promises to notify the client (via a callback request) if another client
+attempts to access that file.
+Once a file has been delegated to a client, the client can
+cache that file's data and metadata aggressively without
+contacting the server.
+.P
+File delegations come in two flavors:
+.I read