LinuxGuruz
Toll Free Numbers
  • Last 5 Forum Topics
    Replies
    Views
    Last post


The Web Only This Site
  • BOOKMARK

  • ADD TO FAVORITES

  • REFERENCES


  • MARC

    Mailing list ARChives
    - Search by -
     Subjects
     Authors
     Bodies





    FOLDOC

    Computing Dictionary




  • Text Link Ads
  • LINUX man pages
  • Linux Man Page Viewer


    The following form allows you to view linux man pages.

    Command:

    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-
                          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
                          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
           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
                          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
    
                          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.
                          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
                          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.
    
                          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-
    
           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
                          discusses 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.
    
                   [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
    
           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-
           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.
           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-
           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
           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
           translation  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
           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)
    
  • MORE RESOURCE


  • Linux

    The Distributions





    Linux

    The Software





    Linux

    The News



  • MARKETING






  • Toll Free

Toll Free Numbers

webmaster@linuxguruz.com
Copyright © 1999 - 2016 by LinuxGuruz