]> git.decadent.org.uk Git - nfs-utils.git/blobdiff - utils/mount/nfs.man
nfs(5): document new [no]resvport option
[nfs-utils.git] / utils / mount / nfs.man
index bc1a6c6aefadbba3c33707445486b8851972ba4f..13de5245204c5138d05d476c80b07011bee8ee85 100644 (file)
@@ -121,25 +121,29 @@ option.
 .BI timeo= n
 The time (in tenths of a second) the NFS client waits for a 
 response before it retries an NFS request. If this 
-option is not specified, requests are retried after 
-60 seconds for NFS over TCP, and are retried after 7/10 of a second for
-NFS over UDP.
+option is not specified, requests are retried every
+60 seconds for NFS over TCP.
+The NFS client does not perform any kind of timeout backoff
+for NFS over TCP.
 .IP
-For NFS over TCP, the client uses a fixed timeout, as specified by the
-.B timeo
-option. However, for NFS over UDP, the client uses an adaptive
+However, for NFS over UDP, the client uses an adaptive
 algorithm to estimate an appropriate timeout value for frequently used
 request types (such as READ and WRITE requests), but uses the 
 .B timeo
 setting for infrequently used request types (such as FSINFO requests).
-After each retransmission, the NFS client doubles the timeout for that
-request, up to a maximum timeout length of 60 seconds.
+If the
+.B timeo
+option is not specified,
+infrequently used request types are retried after 1.1 seconds.
+After each retransmission, the NFS client doubles the timeout for
+that request,
+up to a maximum timeout length of 60 seconds.
 .TP 1.5i
 .BI retrans= n
 The number of times the NFS client retries a request before
 it attempts further recovery action. If the 
 .B retrans
-option is not specified, the NFS client retries each request 
+option is not specified, the NFS client tries each request 
 three times.
 .IP
 The NFS client generates a "server not responding" message
@@ -401,21 +405,38 @@ is legacy caching behavior. This
 is considered a data risk since multiple cached copies
 of the same file on the same client can become out of sync
 following a local update of one of the copies.
+.TP 1.5i
+.BR resvport " / " noresvport
+Specifies whether the NFS client should use a privileged source port
+when communicating with an NFS server for this mount point.
+If this option is not specified, or the
+.B resvport
+option is specified, the NFS client uses a privileged source port.
+If the
+.B noresvport
+option is specified, the NFS client uses a non-privileged source port.
+This option is supported in kernels 2.6.28 and later.
+.IP
+Using non-privileged source ports helps increase the maximum number of
+NFS mount points allowed on a client, but NFS servers must be configured
+to allow clients to connect via non-privileged source ports.
+.IP
+Refer to the SECURITY CONSIDERATIONS section for important details.
 .SS "Valid options for the nfs file system type"
 Use these options, along with the options in the above subsection,
 for mounting the
 .B nfs
 file system type.
 .TP 1.5i
-.BI proto= netid
-The transport protocol used by the NFS client
+.BI proto= transport
+The transport the NFS client uses
 to transmit requests to the NFS server for this mount point.
-.I netid
+.I transport
 can be either
 .B udp
 or
 .BR tcp .
-Each transport protocol uses different default
+Each transport uses different default
 .B retrans
 and
 .B timeo
@@ -485,6 +506,30 @@ or the server's mountd service is not available on the advertised port.
 This option can be used when mounting an NFS server
 through a firewall that blocks the rpcbind protocol.
 .TP 1.5i
+.BI mountproto= transport
+The transport 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.
+.I transport
+can be either
+.B udp
+or
+.BR tcp .
+.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.
+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
@@ -567,6 +612,13 @@ Using the
 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.
@@ -615,10 +667,10 @@ for mounting the
 .B nfs4
 file system type.
 .TP 1.5i
-.BI proto= netid
-The transport protocol used by the NFS client
+.BI proto= transport
+The transport the NFS client uses
 to transmit requests to the NFS server for this mount point.
-.I netid
+.I transport
 can be either
 .B udp
 or
@@ -661,6 +713,13 @@ Using the
 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
@@ -808,6 +867,84 @@ 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.
@@ -1106,6 +1243,55 @@ The Linux client specifies a single security flavor at mount time
 which remains in effect for the lifetime of the mount.
 If the server does not support this flavor,
 the initial mount request is rejected by the server.
+.SS "Using non-privileged source ports"
+NFS clients usually communicate with NFS servers via network sockets.
+Each end of a socket is assigned a port value, which is simply a number
+between 1 and 65535 that distinguishes socket endpoints at the same
+IP address.
+A socket is uniquely defined by a tuple that includes the transport
+protocol (TCP or UDP) and the port values and IP addresses of both
+endpoints.
+.P
+The NFS client can choose any source port value for its sockets,
+but usually chooses a
+.I privileged
+port.
+A privileged port is a port value less than 1024.
+Only a process with root privileges may create a socket
+with a privileged source port.
+.P
+The exact range of privileged source ports that can be chosen is
+set by a pair of sysctls to avoid choosing a well-known port, such as
+the port used by ssh.
+This means the number of source ports available for the NFS client,
+and therefore the number of socket connections that can be used
+at the same time,
+is practically limited to only a few hundred.
+.P
+As described above, the traditional default NFS authentication scheme,
+known as AUTH_SYS, relies on sending local UID and GID numbers to identify
+users making NFS requests.
+An NFS server assumes that if a connection comes from a privileged port,
+the UID and GID numbers in the NFS requests on this connection have been
+verified by the client's kernel or some other local authority.
+This is an easy system to spoof, but on a trusted physical network between
+trusted hosts, it is entirely adequate.
+.P
+Roughly speaking, one socket is used for each NFS mount point.
+If a client could use non-privileged source ports as well,
+the number of sockets allowed,
+and thus the maximum number of concurrent mount points,
+would be much larger.
+.P
+Using non-privileged source ports may compromise server security somewhat,
+since any user on AUTH_SYS mount points can now pretend to be any other
+when making NFS requests.
+Thus NFS servers do not support this by default.
+They explicitly allow it usually via an export option.
+.P
+To retain good security while allowing as many mount points as possible,
+it is best to allow non-privileged client connections only if the server
+and client both require strong authentication, such as Kerberos.
 .SS "Mounting through a firewall"
 A firewall may reside between an NFS client and server,
 or the client or server may block some of its own ports via IP
@@ -1211,6 +1397,8 @@ such as security negotiation, server referrals, and named attributes.
 .BR umount.nfs (5),
 .BR exports (5),
 .BR nfsd (8),
+.BR sm-notify (8),
+.BR rpc.statd (8),
 .BR rpc.idmapd (8),
 .BR rpc.gssd (8),
 .BR rpc.svcgssd (8),