nfs

NFS(5)                        File Formats Manual                       NFS(5)

NAME
       nfs - fstab format and options for the nfs file systems

SYNOPSIS
       /etc/fstab

DESCRIPTION
       NFS  is  an  Internet  Standard protocol created by Sun Microsystems in
       1984. NFS was developed to allow file sharing between systems  residing
       on  a local area network.  The Linux NFS client supports three versions
       of the NFS protocol: NFS version 2 [RFC1094], NFS version 3  [RFC1813],
       and NFS version 4 [RFC3530].

       The  mount(8) command attaches a file system to the system's name space
       hierarchy at a given mount point.  The /etc/fstab  file  describes  how
       mount(8)  should  assemble  a system's file name hierarchy from various
       independent file  systems  (including  file  systems  exported  by  NFS
       servers).   Each  line  in  the /etc/fstab file describes a single file
       system, its mount point, and a set of default mount  options  for  that
       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.  The fifth and sixth fields on each line are
       not  used  by NFS, thus conventionally each contain the digit zero. For
       example:

               server:path   /mountpoint   fstype   option,option,...   0 0

       The server's hostname and export pathname are  separated  by  a  colon,
       while  the  mount options are separated by commas. The remaining fields
       are separated by blanks or tabs.

       The server's hostname can be an unqualified hostname, a fully qualified
       domain name, a dotted quad IPv4 address, or an IPv6 address enclosed in
       square brackets.  Link-local and  site-local  IPv6  addresses  must  be
       accompanied  by  an  interface  identifier.  See ipv6(7) for details on
       specifying raw IPv6 addresses.

       The  fstype  field  contains  "nfs".   Use  of  the  "nfs4"  fstype  in
       /etc/fstab is deprecated.

MOUNT OPTIONS
       Refer  to mount(8) for a description of generic mount options available
       for all file systems. If you do not need to specify any mount  options,
       use the generic option defaults in /etc/fstab.

   Options supported by all versions
       These options are valid to use with any NFS version.

       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 negotiates  a  suit-
                      able  version  with  the server, trying version 4 first,
                      version 3 second, and version 2 last.

       vers=n         This option is an alternative to the nfsvers option.  It
                      is  included for compatibility with other operating sys-
                      tems

       soft / hard    Determines the recovery behavior of the NFS client after
                      an  NFS  request times out.  If neither option is speci-
                      fied (or if the hard option is specified), NFS  requests
                      are  retried indefinitely.  If the soft option is speci-
                      fied, then the NFS client fails  an  NFS  request  after
                      retrans  retransmissions have been sent, causing the NFS
                      client to return an error to the calling application.

                      NB: A so-called "soft" timeout  can  cause  silent  data
                      corruption  in  certain  cases.  As  such,  use the soft
                      option only when client responsiveness is more important
                      than  data  integrity.  Using NFS over TCP or increasing
                      the value of the retrans option may mitigate some of the
                      risks of using the soft option.

       intr / nointr  This  option is provided for backward compatibility.  It
                      is ignored after kernel 2.6.25.

       timeo=n        The time in deciseconds (tenths of  a  second)  the  NFS
                      client  waits  for  a  response before it retries an NFS
                      request.

                      For NFS over TCP the default timeo value is 600 (60 sec-
                      onds).   The  NFS  client performs linear backoff: After
                      each retransmission the timeout is increased by timeo up
                      to the maximum of 600 seconds.

                      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 timeo setting  for  infrequently
                      used  request  types  (such as FSINFO requests).  If the
                      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 sec-
                      onds.

       retrans=n      The number of times the NFS  client  retries  a  request
                      before  it  attempts  further  recovery  action.  If the
                      retrans option is not specified, the  NFS  client  tries
                      each UDP request three times and each TCP request twice.

                      The  NFS client generates a "server not responding" mes-
                      sage after retrans retries, then attempts further recov-
                      ery  (depending  on  whether the hard mount option is in
                      effect).

       rsize=n        The maximum number of bytes in each network READ request
                      that the NFS client can receive 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 setting. The largest read payload supported by the
                      Linux NFS client is 1,048,576 bytes (one megabyte).

                      The rsize value is a positive integral multiple of 1024.
                      Specified rsize values lower than 1024 are replaced with
                      4096;  values  larger  than  1048576  are  replaced with
                      1048576. If a specified value is  within  the  supported
                      range  but not a multiple of 1024, it is rounded down to
                      the nearest multiple of 1024.

                      If an rsize value is not specified, or if the  specified
                      rsize  value  is  larger  than  the  maximum that either
                      client or server can  support,  the  client  and  server
                      negotiate  the  largest  rsize  value that they can both
                      support.

                      The rsize mount option as specified on the mount(8) com-
                      mand  line  appears  in the /etc/mtab file. However, 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 send when writing data to a file
                      on  an  NFS server. The actual data payload size of each
                      NFS WRITE request is equal to or smaller than the  wsize
                      setting.  The  largest  write  payload  supported by the
                      Linux NFS client is 1,048,576 bytes (one megabyte).

                      Similar to rsize , the wsize value is a  positive  inte-
                      gral  multiple  of  1024.   Specified wsize values lower
                      than 1024 are replaced with  4096;  values  larger  than
                      1048576  are replaced with 1048576. If a specified value
                      is within the supported range  but  not  a  multiple  of
                      1024,  it  is  rounded  down  to the nearest multiple of
                      1024.

                      If a wsize value is not specified, or if  the  specified
                      wsize  value  is  larger  than  the  maximum that either
                      client or server can  support,  the  client  and  server
                      negotiate  the  largest  wsize  value that they can both
                      support.

                      The wsize mount option as specified on the mount(8) com-
                      mand  line  appears  in the /etc/mtab file. However, the
                      effective wsize  value  negotiated  by  the  client  and
                      server is reported in the /proc/mounts file.

       ac / noac      Selects whether the client may cache file attributes. If
                      neither option is specified (or if ac is specified), the
                      client caches file attributes.

                      To   improve   performance,   NFS   clients  cache  file
                      attributes. Every few seconds, an NFS client checks  the
                      server's  version of each file's attributes for updates.
                      Changes that occur on the server in those  small  inter-
                      vals  remain  undetected  until  the  client  checks the
                      server again. The  noac  option  prevents  clients  from
                      caching  file  attributes  so that applications can more
                      quickly detect file changes on the server.

                      In addition to preventing the client from  caching  file
                      attributes, the noac option forces application writes to
                      become synchronous so  that  local  changes  to  a  file
                      become  visible  on  the  server immediately.  That way,
                      other clients can quickly detect recent writes when they
                      check the file's attributes.

                      Using  the  noac option provides greater cache coherence
                      among NFS clients  accessing  the  same  files,  but  it
                      extracts  a  significant  performance penalty.  As such,
                      judicious use of file  locking  is  encouraged  instead.
                      The  DATA  AND  METADATA  COHERENCE  section  contains a
                      detailed discussion of these trade-offs.

       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.  If this option  is
                      not  specified,  the NFS client uses a 3-second minimum.
                      See the DATA AND METADATA COHERENCE section for  a  full
                      discussion of attribute caching.

       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.  If this option is
                      not specified, the NFS client uses a 60-second  maximum.
                      See  the  DATA AND METADATA COHERENCE section for a full
                      discussion of attribute caching.

       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.  If this option  is
                      not  specified, the NFS client uses a 30-second minimum.
                      See the DATA AND METADATA COHERENCE section for  a  full
                      discussion of attribute caching.

       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.  If this option is
                      not specified, the NFS client uses a 60-second  maximum.
                      See  the  DATA AND METADATA COHERENCE section for a full
                      discussion of attribute caching.

       actimeo=n      Using actimeo sets all of acregmin, acregmax,  acdirmin,
                      and  acdirmax  to the same value.  If this option is not
                      specified, the NFS client uses the defaults for each  of
                      these options listed above.

       bg / fg        Determines  how  the  mount(8)  command  behaves  if  an
                      attempt to mount an export 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 the fg nor bg mount option is specified.

                      If the bg option is  specified,  a  timeout  or  failure
                      causes  the  mount(8) command to fork a child which con-
                      tinues to attempt to mount the export.  The parent imme-
                      diately 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 acts as if the mount request timed out.
                      This permits nested NFS mounts specified  in  /etc/fstab
                      to  proceed  in  any order during system initialization,
                      even if some NFS servers are not yet available.   Alter-
                      natively  these  issues  can be addressed using an auto-
                      mounter (refer to automount(8) for details).

       rdirplus / nordirplus
                      Selects  whether  to  use  NFS  v3  or  v4   READDIRPLUS
                      requests.   If  this  option  is  not specified, the NFS
                      client uses READDIRPLUS requests on NFS v3 or v4  mounts
                      to  read  small  directories.  Some applications perform
                      better if the client uses only READDIR requests for  all
                      directories.

       retry=n        The  number of minutes that the mount(8) command retries
                      an NFS mount operation in the foreground  or  background
                      before  giving up.  If this option is not specified, the
                      default value for foreground mounts is  2  minutes,  and
                      the default value for background mounts is 10000 minutes
                      (80 minutes shy of one week).  If a  value  of  zero  is
                      specified,  the mount(8) command exits immediately after
                      the first failure.

                      Note that this only affects how many  retries  are  made
                      and  doesn't affect the delay caused by each retry.  For
                      UDP each retry takes the time determined  by  the  timeo
                      and  retrans  options,  which by default will be about 7
                      seconds.  For TCP the default is 3 minutes,  but  system
                      TCP connection timeouts will sometimes limit the timeout
                      of each retransmission to around 2 minutes.

       sec=flavors    A colon-separated list of one or more  security  flavors
                      to use for accessing files on the mounted export. If the
                      server does not support any of these flavors, the  mount
                      operation  fails.   If sec= is not specified, the client
                      attempts to find a security flavor that both the  client
                      and  the  server supports.  Valid flavors are none, sys,
                      krb5, krb5i, and krb5p.  Refer to the SECURITY CONSIDER-
                      ATIONS section for details.

       sharecache / nosharecache
                      Determines  how  the  client's  data cache and attribute
                      cache are shared when mounting the same export more than
                      once  concurrently.  Using the same cache reduces memory
                      requirements on the client and presents  identical  file
                      contents  to  applications  when the same remote file is
                      accessed via different mount points.

                      If neither option is specified,  or  if  the  sharecache
                      option is specified, then a single cache is used for all
                      mount points  that  access  the  same  export.   If  the
                      nosharecache  option is specified, then that mount point
                      gets a unique cache.  Note that when data and  attribute
                      caches  are  shared,  the  mount  options from the first
                      mount point take effect for subsequent concurrent mounts
                      of the same export.

                      As  of kernel 2.6.18, the behavior specified by noshare-
                      cache 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.

       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 resvport option is specified, the NFS client uses  a
                      privileged  source  port.   If  the noresvport option is
                      specified, the NFS client uses a  non-privileged  source
                      port.   This  option  is supported in kernels 2.6.28 and
                      later.

                      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.

                      Refer  to the SECURITY CONSIDERATIONS section for impor-
                      tant details.

       lookupcache=mode
                      Specifies how the kernel manages its cache of  directory
                      entries  for  a  given  mount point.  mode can be one of
                      all, none, pos, or positive.  This option  is  supported
                      in kernels 2.6.28 and later.

                      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 positive.  If
                      the requested directory entry  does  not  exist  on  the
                      server, the result is referred to as negative.

                      If this option is not specified, or if all is specified,
                      the client assumes both types of directory cache entries
                      are   valid   until   their  parent  directory's  cached
                      attributes expire.

                      If pos or positive is specified, the client assumes pos-
                      itive  entries  are valid until their parent directory's
                      cached attributes expire, but always  revalidates  nega-
                      tive entires before an application can use them.

                      If  none is specified, the client revalidates both types
                      of directory cache entries before an application can use
                      them.   This  permits quick detection of files that were
                      created or removed by  other  clients,  but  can  impact
                      application and server performance.

                      The  DATA  AND  METADATA  COHERENCE  section  contains a
                      detailed discussion of these trade-offs.

       fsc / nofsc    Enable/Disables the cache of (read-only) data  pages  to
                      the   local   disk  using  the  FS-Cache  facility.  See
                      cachefilesd(8)      and       <kernel_soruce>/Documenta-
                      tion/filesystems/caching  for detail on how to configure
                      the FS-Cache facility.  Default value is nofsc.

   Options for NFS versions 2 and 3 only
       Use these options, along with the options in the above subsection,  for
       NFS versions 2 and 3 only.

       proto=netid    The  netid determines the transport that is used to com-
                      municate with the NFS  server.   Available  options  are
                      udp,  udp6,  tcp,  tcp6, and rdma.  Those which end in 6
                      use IPv6 addresses and are only available if support for
                      TI-RPC is built in. Others use IPv4 addresses.

                      Each  transport  protocol uses different default retrans
                      and timeo settings.  Refer to the description  of  these
                      two mount options for details.

                      In  addition to controlling how the NFS client transmits
                      requests to the server, this mount option also  controls
                      how  the mount(8) command communicates with the server's
                      rpcbind and mountd services.  Specifying  a  netid  that
                      uses  TCP  forces  all traffic from the mount(8) command
                      and the NFS client to use TCP.  Specifying a netid  that
                      uses UDP forces all traffic types to use UDP.

                      Before  using NFS over UDP, refer to the TRANSPORT METH-
                      ODS section.

                      If the proto mount option is not specified, the mount(8)
                      command  discovers  which  protocols the server supports
                      and chooses an appropriate transport for  each  service.
                      Refer to the TRANSPORT METHODS section for more details.

       udp            The   udp   option   is  an  alternative  to  specifying
                      proto=udp.  It is included for compatibility with  other
                      operating systems.

                      Before  using NFS over UDP, refer to the TRANSPORT METH-
                      ODS section.

       tcp            The  tcp  option  is  an   alternative   to   specifying
                      proto=tcp.   It is included for compatibility with other
                      operating systems.

       rdma           The  rdma  option  is  an  alternative   to   specifying
                      proto=rdma.

       port=n         The  numeric value of the server's NFS service port.  If
                      the server's NFS service is not available on the  speci-
                      fied port, the mount request fails.

                      If  this  option  is  not specified, or if the specified
                      port value is 0, then the NFS client uses the  NFS  ser-
                      vice port number advertised by the server's rpcbind ser-
                      vice.  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.

       mountport=n    The  numeric  value of the server's mountd port.  If the
                      server's mountd service is not available on  the  speci-
                      fied port, the mount request fails.

                      If  this  option  is  not specified, or if the specified
                      port value is 0, then  the  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  ser-
                      vice, 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.

       mountproto=netid
                      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.

                      netid may be one of udp, and tcp which use IPv4  address
                      or, if TI-RPC is built into the mount.nfs command, udp6,
                      and tcp6 which use IPv6 addresses.

                      This option can be used  when  mounting  an  NFS  server
                      through  a  firewall that blocks a particular transport.
                      When used in combination with the proto option,  differ-
                      ent  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  mountproto  mount  option  interacts with the proto
                      mount option.

       mounthost=name The hostname of the host running mountd.  If this option
                      is  not specified, the mount(8) command assumes that the
                      mountd service runs on the same host as the NFS service.

       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 ser-
                      vices are running on the same remote server host.

       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.

                      Some early versions of NFS did not support this negotia-
                      tion.   Using  this  option  ensures  that   pathconf(3)
                      reports  the proper maximum component length to applica-
                      tions in such cases.

       lock / nolock  Selects whether to use the NLM sideband protocol to lock
                      files on the server.  If neither option is specified (or
                      if lock is specified), NLM  locking  is  used  for  this
                      mount point.  When using the 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.

                      NLM locking must be disabled with the nolock option when
                      using NFS to mount /var because /var contains files used
                      by the NLM implementation on Linux.   Using  the  nolock
                      option  is  also  required  when mounting exports on NFS
                      servers that do not support the NLM protocol.

       cto / nocto    Selects whether to  use  close-to-open  cache  coherence
                      semantics.  If neither option is specified (or if cto is
                      specified), the client uses close-to-open  cache  coher-
                      ence  semantics.  If  the nocto option is specified, the
                      client uses a non-standard heuristic to  determine  when
                      files on the server have changed.

                      Using the 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.

       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.

                      If  neither  acl  nor 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 sup-
                      ports 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.

       local_lock=mechanism
                      Specifies  whether  to use local locking for any or both
                      of the flock and the POSIX locking  mechanisms.   mecha-
                      nism  can  be  one  of all, flock, posix, or none.  This
                      option is supported in kernels 2.6.37 and later.

                      The Linux NFS client provides a way to make locks local.
                      This  means,  the  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.

                      If this option is not specified, or if  none  is  speci-
                      fied, the client assumes that the locks are not local.

                      If  all is specified, the client assumes that both flock
                      and POSIX locks are local.

                      If flock is specified,  the  client  assumes  that  only
                      flock  locks are local and uses NLM sideband protocol to
                      lock files when POSIX locks are used.

                      If posix is specified, the  client  assumes  that  POSIX
                      locks  are  local and uses NLM sideband protocol to lock
                      files when flock locks are used.

                      To support legacy flock behavior similar to that of  NFS
                      clients < 2.6.12, use 'local_lock=flock'. This option is
                      required when exporting NFS mounts via  Samba  as  Samba
                      maps  Windows  share  mode  locks  as  flock.  Since NFS
                      clients > 2.6.12  implement  flock  by  emulating  POSIX
                      locks, this will result in conflicting locks.

                      NOTE:  When used together, the 'local_lock' mount option
                      will be overridden by 'nolock'/'lock' mount option.

   Options for NFS version 4 only
       Use these options, along with  the  options  in  the  first  subsection
       above, for NFS version 4 and newer.

       proto=netid    The  netid determines the transport that is used to com-
                      municate with the NFS  server.   Supported  options  are
                      tcp,  tcp6,  and  rdma.   tcp6 use IPv6 addresses and is
                      only available if support for TI-RPC is built  in.  Both
                      others use IPv4 addresses.

                      All  NFS  version 4 servers are required to support TCP,
                      so if this mount option is not specified, the  NFS  ver-
                      sion  4  client  uses  the  TCP  protocol.  Refer to the
                      TRANSPORT METHODS section for more details.

       port=n         The numeric value of the server's NFS service port.   If
                      the  server's NFS service is not available on the speci-
                      fied port, the mount request fails.

                      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.

                      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.

       cto / nocto    Selects whether to  use  close-to-open  cache  coherence
                      semantics  for  NFS directories on this mount point.  If
                      neither cto nor nocto is specified, the  default  is  to
                      use close-to-open cache coherence semantics for directo-
                      ries.

                      File data caching  behavior  is  not  affected  by  this
                      option.   The  DATA  AND METADATA COHERENCE section dis-
                      cusses the behavior of this option in more detail.

       clientaddr=n.n.n.n

       clientaddr=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.

                      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  atypi-
                      cal  network  topologies,  the  exact address to use for
                      callbacks may be nontrivial to determine.

       migration / nomigration
                      Selects whether the client uses an identification string
                      that  is  compatible with NFSv4 Transparent State Migra-
                      tion (TSM).  If the mounted server supports NFSv4 migra-
                      tion with TSM, specify the migration option.

                      Some  server  features misbehave in the face of a migra-
                      tion-compatible identification string.  The  nomigration
                      option  retains the use of a traditional client indenti-
                      fication string which  is  compatible  with  legacy  NFS
                      servers.  This is also the behavior if neither option is
                      specified.  A client's open and  lock  state  cannot  be
                      migrated  transparently  when it identifies itself via a
                      traditional identification string.

                      This mount option has no effect with  NFSv4  minor  ver-
                      sions  newer  than zero, which always use TSM-compatible
                      client identification strings.

nfs4 FILE SYSTEM TYPE
       The nfs4 file system type is an old syntax for specifying NFSv4  usage.
       It  can  still  be  used  with  all  NFSv4-specific and common options,
       excepted the nfsvers mount option.

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
       /etc/nfsmount.conf file. See nfsmount.conf(5) for details.

EXAMPLES
       To mount an export 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 either the nfs file system type, with
       the nfsvers=4 mount option, or the nfs4 file system type.

       The following example from an /etc/fstab file causes the mount  command
       to negotiate reasonable defaults for NFS behavior.

               server:/export  /mnt  nfs   defaults                      0 0

       Here  is  an example from an /etc/fstab file for an NFS version 2 mount
       over UDP.

               server:/export  /mnt  nfs   nfsvers=2,proto=udp           0 0

       This example shows how to mount using NFS version 4 over TCP with  Ker-
       beros 5 mutual authentication.

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

       This  example shows how to mount using NFS version 4 over TCP with Ker-
       beros 5 privacy or data integrity mode.

               server:/export  /mnt  nfs4  sec=krb5p:krb5i               0 0

       This example can be used to mount /usr over NFS.

               server:/export  /usr  nfs   ro,nolock,nocto,actimeo=3600  0 0

       This example shows how to mount an NFS server using a  raw  IPv6  link-
       local address.

               [fe80::215:c5ff:fb3e:e2b1%eth0]:/export /mnt nfs defaults 0 0

TRANSPORT METHODS
       NFS clients send requests to NFS servers via Remote Procedure Calls, or
       RPCs.  The RPC client discovers remote service endpoints automatically,
       handles per-request authentication, adjusts request parameters for dif-
       ferent 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.

       In most cases, the mount(8) command, NFS client,  and  NFS  server  can
       automatically  negotiate  proper  transport and data transfer size set-
       tings for a mount point.  In some cases, however, it  pays  to  specify
       these settings explicitly using mount options.

       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.

       However, UDP can be quite effective in specialized settings  where  the
       networks MTU is large relative to NFSs data transfer size (such as net-
       work environments that enable jumbo Ethernet frames).  In such environ-
       ments,  trimming  the rsize and 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.

       TCP is the default transport protocol used for all modern NFS implemen-
       tations.  It performs well in almost every conceivable network environ-
       ment  and  provides excellent guarantees against data corruption caused
       by network unreliability.  TCP is often a requirement  for  mounting  a
       server through a network firewall.

       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 set-
       tings for NFS over TCP are between one and  ten  minutes.   After   the
       client  exhausts  its  retransmits  (the  value  of  the  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 net-
       work data transfer reliable, rsize and wsize can safely be  allowed  to
       default  to  the  largest  values  supported by both client and server,
       independent of the network's MTU size.

   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.

       The  Linux  NFS  client can use a different transport for contacting an
       NFS server's rpcbind service, its mountd service, its Network Lock Man-
       ager (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 proto, mountproto, udp, and
       tcp.

       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.

       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.

       If the server does not support these transports for these services, the
       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 bg option is in
       effect, the mount command backgrounds itself and continues  to  attempt
       the specified mount request.

       When  the  proto option, the udp option, or the tcp option is specified
       but the mountproto option is not, the specified transport  is  used  to
       contact  both  the server's mountd service and for the NLM and NFS ser-
       vices.

       If the mountproto option is specified but none of the 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 trans-
       ports are supported.

       If both the mountproto and proto (or udp or tcp) options are specified,
       then  the  transport specified by the mountproto option is used for the
       initial mountd request, and the transport specified by the proto option
       (or the 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.

       If any of the proto, udp, tcp, or mountproto options are specified more
       than once on the same mount command line, then the value of the  right-
       most instance of each of these options takes effect.

   Using NFS over UDP on high-speed links
       Using NFS over UDP on high-speed links such as Gigabit can cause silent
       data corruption.

       The problem can be triggered at high loads, and is caused  by  problems
       in  IP  fragment reassembly. NFS read and writes typically transmit UDP
       packets of 4 Kilobytes or more, which have to be broken up into several
       fragments  in  order  to  be  sent over the Ethernet link, which limits
       packets to 1500 bytes by default. This process happens at the  IP  net-
       work layer and is called fragmentation.

       In order to identify fragments that belong together, IP assigns a 16bit
       IP ID value to each packet;  fragments  generated  from  the  same  UDP
       packet  will  have  the  same  IP ID. The receiving system will collect
       these fragments and combine them to form the original UDP packet.  This
       process is called reassembly. The default timeout for packet reassembly
       is 30 seconds; if the network stack does not receive all fragments of a
       given  packet  within this interval, it assumes the missing fragment(s)
       got lost and discards those it already received.

       The problem this creates over high-speed links is that it  is  possible
       to  send more than 65536 packets within 30 seconds. In fact, with heavy
       NFS traffic one can observe that the IP IDs repeat after about  5  sec-
       onds.

       This  has  serious  effects  on  reassembly: if one fragment gets lost,
       another fragment from a different packet but with the same IP  ID  will
       arrive within the 30 second timeout, and the network stack will combine
       these fragments to form a new packet. Most of the time, network  layers
       above  IP  will detect this mismatched reassembly - in the case of UDP,
       the UDP checksum, which is a 16 bit checksum  over  the  entire  packet
       payload, will usually not match, and UDP will discard the bad packet.

       However,  the UDP checksum is 16 bit only, so there is a chance of 1 in
       65536 that it will match even if the packet payload is completely  ran-
       dom (which very often isn't the case). If that is the case, silent data
       corruption will occur.

       This potential should be taken seriously, at least on Gigabit Ethernet.
       Network  speeds  of  100Mbit/s  should  be considered less problematic,
       because with most traffic patterns IP ID wrap  around  will  take  much
       longer than 30 seconds.

       It  is  therefore strongly recommended to use NFS over TCP where possi-
       ble, since TCP does not perform fragmentation.

       If you absolutely have to use NFS over UDP over Gigabit Ethernet,  some
       steps  can  be taken to mitigate the problem and reduce the probability
       of corruption:

       Jumbo frames:  Many Gigabit network cards are capable  of  transmitting
                      frames  bigger  than  the 1500 byte limit of traditional
                      Ethernet, typically 9000 bytes. Using  jumbo  frames  of
                      9000  bytes will allow you to run NFS over UDP at a page
                      size of 8K without fragmentation.  Of  course,  this  is
                      only  feasible  if  all  involved stations support jumbo
                      frames.

                      To enable a machine to send jumbo frames on  cards  that
                      support  it, it is sufficient to configure the interface
                      for a MTU value of 9000.

       Lower reassembly timeout:
                      By lowering this timeout below the time it takes the  IP
                      ID counter to wrap around, incorrect reassembly of frag-
                      ments can be prevented as well. To do so,  simply  write
                      the   new   timeout  value  (in  seconds)  to  the  file
                      /proc/sys/net/ipv4/ipfrag_time.

                      A value of 2 seconds will greatly reduce the probability
                      of  IPID  clashes  on a single Gigabit link, while still
                      allowing for a reasonable timeout when  receiving  frag-
                      mented traffic from distant peers.

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.

   Close-to-open cache consistency
       Typically  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.

       When an application opens a file stored on an NFS version 3 server, the
       NFS client checks that the file exists on the server and  is  permitted
       to  the  opener by sending a GETATTR or ACCESS request.  The NFS client
       sends these requests regardless of the freshness of the  file's  cached
       attributes.

       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 write
       errors to the application via the return code from close(2).

       The behavior of checking at open time and flushing  at  close  time  is
       referred to as close-to-open cache consistency, or CTO.  It can be dis-
       abled for an entire mount point using the nocto mount option.

   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 consis-
       tency" (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.

       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.

   Attribute caching
       Use the 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 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.

       Be  careful not to confuse the noac option with "no data caching."  The
       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.

       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.

   File timestamp maintainence
       NFS servers are responsible for managing file and directory  timestamps
       (atime,  ctime,  and  mtime).  When a file is accessed or updated on an
       NFS server, the file's timestamps are updated just like they  would  be
       on a filesystem local to an application.

       NFS  clients  cache  file  attributes,  including timestamps.  A file's
       timestamps are updated on NFS clients when its attributes are retrieved
       from  the  NFS  server.   Thus there may be some delay before timestamp
       updates on an NFS server appear to applications on NFS clients.

       To comply with the POSIX filesystem  standard,  the  Linux  NFS  client
       relies on NFS servers to keep a file's mtime and ctime timestamps prop-
       erly up to date.  It does this by flushing local data  changes  to  the
       server  before reporting mtime to applications via system calls such as
       stat(2).

       The Linux client handles atime  updates  more  loosely,  however.   NFS
       clients  maintain good performance by caching data, but that means that
       application reads, which normally update atime, are  not  reflected  to
       the server where a file's atime is actually maintained.

       Because of this caching behavior, the Linux NFS client does not support
       generic atime-related mount options.  See mount(8) for details on these
       options.

       In particular, the atime/noatime, diratime/nodiratime, relatime/norela-
       time, and strictatime/nostrictatime mount options have no effect on NFS
       mounts.

       /proc/mounts  may  report  that the relatime mount option is set on NFS
       mounts, but in fact the atime semantics are always as  described  here,
       and are not like relatime semantics.

   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 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 negative lookup result.

       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 acdirmin, acdirmax, and  noac
       mount  options  for more information about how long a directory's mtime
       is cached.

       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 lookupcache mount option allows
       some tuning of directory entry caching behavior.

       Before  kernel  release 2.6.28, the Linux NFS client tracked only posi-
       tive lookup results.  This permitted applications to detect new  direc-
       tory  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 lookupcache=positive.

       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 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 noac, and has no effect on how
       the NFS client caches the attributes of files.

   The sync mount option
       The NFS client treats the sync mount option differently than some other
       file systems (refer to mount(8) for a description of the  generic  sync
       and  async  mount options).  If neither sync nor async is specified (or
       if the async option is specified), the NFS client delays sending appli-
       cation writes to the server until any of these events occur:

              Memory pressure forces reclamation of system memory resources.

              An  application  flushes  file  data  explicitly  with  sync(2),
              msync(2), or fsync(3).

              An application closes a file with close(2).

              The file is locked/unlocked via fcntl(2).

       In other words, under normal circumstances, data written by an applica-
       tion may not immediately appear on the server that hosts the file.

       If  the 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 sig-
       nificant performance cost.

       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 sync mount option.

   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 pro-
       tocol, and the NLM and NSM sideband protocols are not used.

       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.

       NLM supports advisory file locks only.  To lock NFS files, use fcntl(2)
       with the F_GETLK and F_SETLK commands.  The NFS  client  converts  file
       locks obtained via flock(2) to advisory locks.

       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  nolock  mount option. NLM locking must be disabled
       with the nolock option when using NFS to mount /var because  /var  con-
       tains files used by the NLM implementation on Linux.

       Specifying the nolock option may also be advised to improve the perfor-
       mance of a proprietary application which runs on a  single  client  and
       uses file locks extensively.

   NFS version 4 caching features
       The data and metadata caching behavior of NFS version 4 clients is sim-
       ilar to that of earlier versions.  However, NFS version 4 adds two fea-
       tures  that  improve cache behavior: change attributes and file delega-
       tion.

       The change attribute is a new part of NFS file and  directory  metadata
       which  tracks  data changes.  It replaces the use of a file's modifica-
       tion and change time stamps as a way for clients to validate  the  con-
       tent  of  their  caches.  Change attributes are independent of the time
       stamp resolution on either the server or client, however.

       A 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.

       File delegations come in two flavors: read and write.  A  read  delega-
       tion  means that the server notifies the client about any other clients
       that want to write to the file.  A  write  delegation  means  that  the
       client gets notified about either read or write accessors.

       Servers  grant  file  delegations when a file is opened, and can recall
       delegations at any time when another client wants access  to  the  file
       that  conflicts  with  any delegations already granted.  Delegations on
       directories are not supported.

       In order to support delegation callback, the server checks the  network
       return  path to the client during the client's initial contact with the
       server.  If contact with the client cannot be established,  the  server
       simply does not grant any delegations to that client.

SECURITY CONSIDERATIONS
       NFS  servers  control access to file data, but they depend on their 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 mem-
       ber.

       Typically, file data and user ID values appear  unencrypted  (i.e.  "in
       the  clear")  on the network.  Moreover, NFS versions 2 and 3 use sepa-
       rate sideband protocols for mounting, locking and unlocking files,  and
       reporting system status of clients and servers.  These auxiliary proto-
       cols use no authentication.

       In addition to combining these sideband protocols  with  the  main  NFS
       protocol,  NFS  version 4 introduces more advanced forms of access con-
       trol, authentication, and in-transit data protection.  The NFS  version
       4 specification mandates support for strong authentication and security
       flavors  that  provide  per-RPC  integrity  checking  and   encryption.
       Because  NFS  version 4 combines the function of the sideband protocols
       into the main NFS protocol, the new security features apply to all  NFS
       version  4  operations  including  mounting,  file  locking, and so on.
       RPCGSS authentication can also be used with NFS versions 2 and  3,  but
       it does not protect their sideband protocols.

       The  sec mount option specifies the security flavor used for operations
       on behalf of users on that NFS mount point.  Specifying  sec=krb5  pro-
       vides  cryptographic  proof  of  a user's identity in each RPC request.
       This provides strong verification of the identity  of  users  accessing
       data  on the server.  Note that additional configuration besides adding
       this mount option is required in order  to  enable  Kerberos  security.
       Refer to the rpc.gssd(8) man page for details.

       Two  additional  flavors  of Kerberos security are supported: krb5i and
       krb5p.  The krb5i security flavor provides a  cryptographically  strong
       guarantee that the data in each RPC request has not been tampered with.
       The krb5p security flavor encrypts every RPC request  to  prevent  data
       exposure  during  network  transit;  however,  expect  some performance
       impact when using integrity checking or  encryption.   Similar  support
       for other forms of cryptographic security is also available.

   NFS version 4 filesystem crossing
       The  NFS version 4 protocol allows a client to renegotiate the security
       flavor when the client crosses into a new  filesystem  on  the  server.
       The  newly  negotiated flavor effects only accesses of the new filesys-
       tem.

       Such negotiation typically occurs when a client crosses from a server's
       pseudo-fs into one of the server's exported physical filesystems, which
       often have more restrictive security settings than the pseudo-fs.

   NFS version 4 Leases
       In NFS version 4, a lease is a period of time  during  which  a  server
       irrevocably  grants a file lock to a client.  If the lease expires, the
       server is allowed to revoke  that  lock.   Clients  periodically  renew
       their leases to prevent lock revocation.

       After  an  NFS  version  4 server reboots, each client tells the server
       about all file open and lock state under its lease before operation can
       continue.   If  the  client reboots, the server frees all open and lock
       state associated with that client's lease.

       As part of establishing a lease,  therefore,  a  client  must  identify
       itself  to a server.  A fixed string is used to distinguish that client
       from others, and a changeable verifier is used  to  indicate  when  the
       client has rebooted.

       A  client uses a particular security flavor and principal when perform-
       ing the operations to establish a lease.   If  two  clients  happen  to
       present  the same identity string, a server can use their principals to
       detect that they are different clients, and  prevent  one  client  from
       interfering with the other's lease.

       The Linux NFS client establishes one lease for each server.  Lease man-
       agement operations, such as lease renewal, are not done on behalf of  a
       particular file, lock, user, or mount point, but on behalf of the whole
       client that owns that lease.  These operations must use the same  secu-
       rity flavor and principal that was used when the lease was established,
       even across client reboots.

       When Kerberos is configured on a Linux NFS client  (i.e.,  there  is  a
       /etc/krb5.keytab on that client), the client attempts to use a Kerberos
       security flavor for its lease  management  operations.   This  provides
       strong  authentication  of  the  client to each server it contacts.  By
       default, the client uses the host/ or nfs/  service  principal  in  its
       /etc/krb5.keytab for this purpose.

       If  the  client has Kerberos configured, but the server does not, or if
       the client does not have a keytab or the requisite service  principals,
       the client uses AUTH_SYS and UID 0 for lease management.

   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.

       The NFS client can choose any source port value for  its  sockets,  but
       usually  chooses  a 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.

       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.

       As  described above, the traditional default NFS authentication scheme,
       known as AUTH_SYS, relies on sending local UID and GID numbers to iden-
       tify  users  making NFS requests.  An NFS server assumes that if a con-
       nection comes from a privileged port, the UID and GID  numbers  in  the
       NFS requests on this connection have been verified by the client's ker-
       nel 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.

       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.

       Using  non-privileged source ports may compromise server security some-
       what, 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.

       To retain good security while allowing as many mount points  as  possi-
       ble,  it is best to allow non-privileged client connections only if the
       server and client both require strong authentication, such as Kerberos.

   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 filter rules.  It is
       still possible to mount an NFS server through a firewall,  though  some
       of  the  mount(8) command's automatic service endpoint discovery mecha-
       nisms may not work; this requires  you  to  provide  specific  endpoint
       details via NFS mount options.

       NFS  servers  normally  run a portmapper or rpcbind daemon to advertise
       their service endpoints to clients. Clients use the rpcbind  daemon  to
       determine:

              What network port each RPC-based service is using

              What transport protocols each RPC-based service supports

       The  rpcbind daemon uses a well-known port number (111) to help clients
       find a service endpoint.  Although NFS often uses a standard port  num-
       ber  (2049),  auxiliary services such as the NLM service can choose any
       unused port number at random.

       Common firewall configurations block the well-known rpcbind  port.   In
       the  absense  of an rpcbind service, the server administrator fixes the
       port number of NFS-related services so  that  the  firewall  can  allow
       access to specific NFS service ports.  Client administrators then spec-
       ify the port number for the mountd service via the  mount(8)  command's
       mountport  option.   It may also be necessary to enforce the use of TCP
       or UDP if the firewall blocks one of those transports.

   NFS Access Control Lists
       Solaris allows NFS version 3 clients direct access to POSIX Access Con-
       trol Lists stored in its local file systems.  This proprietary sideband
       protocol, known as NFSACL, provides richer  access  control  than  mode
       bits.   Linux  implements  this  protocol  for  compatibility  with the
       Solaris NFS implementation.  The NFSACL protocol never became  a  stan-
       dard part of the NFS version 3 specification, however.

       The  NFS  version 4 specification mandates a new version of Access Con-
       trol Lists that are semantically richer than POSIX ACLs.  NFS version 4
       ACLs  are  not fully compatible with POSIX ACLs; as such, some transla-
       tion between the two is required in an  environment  that  mixes  POSIX
       ACLs and NFS version 4.

THE REMOUNT OPTION
       Generic  mount options such as rw and sync can be modified on NFS mount
       points using the remount option.  See mount(8) for more information  on
       generic mount options.

       With  few  exceptions, NFS-specific options are not able to be modified
       during a remount.  The underlying transport or NFS  version  cannot  be
       changed by a remount, for example.

       Performing a remount on an NFS file system mounted with the noac option
       may have unintended consequences.  The noac option is a combination  of
       the generic option sync, and the NFS-specific option actimeo=0.

   Unmounting after a remount
       For  mount  points that use NFS versions 2 or 3, the NFS umount subcom-
       mand depends on knowing the original set of mount options used to  per-
       form  the  MNT  operation.  These options are stored on disk by the NFS
       mount subcommand, and can be erased by a remount.

       To ensure that the saved mount options are not erased during a remount,
       specify  either  the  local mount directory, or the server hostname and
       export pathname, but not both, during a remount.  For example,

               mount -o remount,ro /mnt

       merges the mount option ro with the mount options already saved on disk
       for the NFS server mounted at /mnt.

FILES
       /etc/fstab     file system table

       /etc/nfsmount.conf
                      Configuration file for NFS mounts

BUGS
       Before 2.4.7, the Linux NFS client did not support NFS over TCP.

       Before  2.4.20,  the  Linux  NFS  client  used a heuristic to determine
       whether cached file data was still valid rather than using the standard
       close-to-open cache coherency method described above.

       Starting with 2.4.22, the Linux NFS client employs a Van Jacobsen-based
       RTT estimator to determine retransmit timeout  values  when  using  NFS
       over UDP.

       Before 2.6.0, the Linux NFS client did not support NFS version 4.

       Before  2.6.8,  the  Linux  NFS  client used only synchronous reads and
       writes when the rsize and wsize settings were smaller than the system's
       page size.

       The  Linux NFS client does not yet support certain optional features of
       the NFS version 4 protocol, such as security negotiation, server refer-
       rals, and named attributes.

SEE ALSO
       fstab(5), mount(8), umount(8), mount.nfs(5), umount.nfs(5), exports(5),
       nfsmount.conf(5),   netconfig(5),   ipv6(7),   nfsd(8),   sm-notify(8),
       rpc.statd(8), rpc.idmapd(8), rpc.gssd(8), rpc.svcgssd(8), kerberos(1)

       RFC 768 for the UDP specification.
       RFC 793 for the TCP specification.
       RFC 1094 for the NFS version 2 specification.
       RFC 1813 for the NFS version 3 specification.
       RFC 1832 for the XDR specification.
       RFC 1833 for the RPC bind specification.
       RFC 2203 for the RPCSEC GSS API protocol specification.
       RFC 3530 for the NFS version 4 specification.

                                9 October 2012                          NFS(5)
Man Pages Copyright Respective Owners. Site Copyright (C) 1994 - 2021 Hurricane Electric. All Rights Reserved.