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, or a dotted quad
       IPv4 address.  The fstype field contains either "nfs" (for version 2 or
       version  3  NFS  mounts) or "nfs4" (for NFS version 4 mounts).  The nfs
       and nfs4 file system types  share  similar  mount  options,  which  are
       described below.

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.

   Valid options for either the nfs or nfs4 file system type
       These  options  are  valid to use when mounting either nfs or nfs4 file
       system types.  They imply the same behavior and have the  same  default
       for both file system types.

       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
                      option is not specified, requests are retried  every  60
                      seconds  for NFS over TCP.  The NFS client does not per-
                      form any kind of timeout backoff for NFS over TCP.

                      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.

       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
                      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
                      attribute  information from a server.  If this option is
                      not specified, the NFS client uses a 30-second minimum.

       acdirmax=n     The maximum time (in seconds) that the NFS client caches
                      attributes  of  a  directory  before  it  requests fresh
                      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).

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

   Valid options for the nfs file system type
       Use these options, along with the options in the above subsection,  for
       mounting the nfs file system type.

       proto=transport
                      The  transport  the NFS client uses to transmit requests
                      to the NFS server for this mount point.   transport  can
                      be  either  udp  or  tcp.  Each transport 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   proto=tcp
                      forces all traffic from the mount(8) command and the NFS
                      client to use  TCP.   Specifying  proto=udp  forces  all
                      traffic types to use UDP.

                      If the proto mount option is not specified, the mount(8)
                      command 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.

       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-
                      through a firewall that blocks the rpcbind protocol.

       mountproto=transport
                      The transport the NFS client uses to  transmit  requests
                      to  the NFS server's mountd service when performing this
                      mount request, and  when  later  unmounting  this  mount
                      point.  transport can be either udp or tcp.

                      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.

       nfsvers=n      The  NFS  protocol  version  number  used to contact the
                      server's NFS service.  The Linux client supports version
                      2  and version 3 of the NFS protocol when using the file
                      system type nfs.  If the server  does  not  support  the
                      requested  version,  the  mount  request fails.  If this
                      option is not specified, the client attempts to use ver-
                      sion  3,  but negotiates the NFS version with the server
                      if version 3 support is not available.

       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
                      ations  on this mount point. If neither option is speci-
                      fied (or if nointr is specified), signals do not  inter-
                      rupt  NFS  file operations. If intr is specified, system
                      calls return EINTR if an in-progress  NFS  operation  is
                      interrupted by a signal.

                      Using  the  intr  option  is preferred to using the soft
                      option because it is significantly less likely to result
                      in data corruption.

                      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.

   Valid options for the nfs4 file system type
       Use  these  options,  along  with  the  options in the first subsection
       above, for mounting the nfs4 file system type.
                      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
                      EINTR  if an in-progress NFS operation is interrupted by
                      a signal.  If nointr is specified, signals do not inter-
                      rupt NFS operations.

                      Using  the  intr  option  is preferred to using the soft
                      option because it is significantly less likely to result
                      in data corruption.

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

       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

       Try this example to mount using NFS version 4 over TCP with Kerberos  5
       mutual authentication.

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

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

            server:/export /usr nfs  ro,nolock,nocto,actimeo=3600  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
       network's  MTU  is  large relative to NFS's data transfer size (such as
       network environments that enable jumbo Ethernet frames).  In such envi-
       ronments,  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  sin-
       gle   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

   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.

DATA AND METADATA COHERENCE
       Some  modern cluster file systems provide perfect cache coherence among
       their clients.  Perfect cache coherence among disparate NFS clients  is
       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-
       open cache consistency.

   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.

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

       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.

       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
       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 (such as lipkey and SPKM3) is
       also available.

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

       ACLs and NFS version 4.

FILES
       /etc/fstab     file system table

BUGS
       The  generic  remount  option is not fully supported.  Generic options,
       such as rw and ro can be modified using the remount  option,  but  NFS-
       specific  options  are  not all supported.  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  mixture  of  a  generic
       option, sync, and an NFS-specific option actimeo=0.

       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),
       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 - 2014 Hurricane Electric. All Rights Reserved.