nfs


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.

       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

       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 request three times.

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

       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.

       acdirmin=n     The minimum time (in seconds) that the NFS client caches
                      attributes  of  a  directory  before  it  requests fresh

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

       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.

       sec=mode       The RPCGSS security flavor to use for accessing files on
                      this mount point.  If the sec option is  not  specified,
                      or  if  sec=sys  is  specified,  the NFS client uses the
                      AUTH_SYS security flavor for all NFS  requests  on  this
                      mount  point.   Valid  security  flavors  are none, sys,
                      krb5, krb5i, krb5p, lkey, lkeyi, lkeyp, spkm, spkmi, and
                      spkmp.  Refer to the SECURITY CONSIDERATIONS 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
                      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.

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

                      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.

       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.

                      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.

       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.

       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

                      The intr / nointr mount option is deprecated after  ker-
                      nel  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.

       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.

       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.

       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.

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

                      If  support  for TI-RPC is built into the mount.nfs com-
                      mand, netid is a valid netid listed  in  /etc/netconfig.
                      Otherwise, netid is one of "tcp" or "udp," and only IPv4
                      may be used.

                      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.

       intr / nointr  Selects whether to allow signals to interrupt file oper-
                      ations on this mount point. If neither option is  speci-
                      fied  (or  if  intr  is  specified), system calls return
                      with older kernels.

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

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.

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

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  sequen-
       tial:  first client A opens a file, writes something to it, then closes
       it; then client B opens the same file, and reads the changes.

   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  applica-
       tion 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 close(2).  The behavior of  check-
       ing at open time and flushing at close time is referred to as close-to-
       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.

   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.

       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
       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 NFSv4 ACLs, RPCGSS authentication, and  RPCGSS
       security  flavors  that  provide per-RPC integrity checking and encryp-
       tion.  Because NFS version 4 combines the function of the sideband pro-
       tocols  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 does not protect their sideband protocols.

       The sec mount option specifies the RPCGSS  security  mode  that  is  in
       effect  on a given NFS mount point.  Specifying sec=krb5 provides cryp-
       tographic proof of a user's identity in each RPC  request.   This  pro-
       vides  strong  verification  of the identity of users accessing data on
       the server.  Note that additional  configuration  besides  adding  this
       The  NFS  version  4  protocol  allows clients and servers to negotiate
       among multiple security  flavors  during  mount  processing.   However,
       Linux does not yet implement such negotiation.  The Linux client speci-
       fies 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.

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

       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),
       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.



                                2 November 2007                         NFS(5)
Man Pages Copyright Respective Owners. Site Copyright (C) 1994 - 2015 Hurricane Electric. All Rights Reserved.