1NFS(5)                        File Formats Manual                       NFS(5)


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


9       /etc/fstab


12       NFS  is  an  Internet  Standard protocol created by Sun Microsystems in
13       1984. NFS was developed to allow file sharing between systems  residing
14       on  a local area network.  Depending on kernel configuration, the Linux
15       NFS client may support NFS versions 3, 4.0, 4.1, or 4.2.
17       The mount(8) command attaches a file system to the system's name  space
18       hierarchy  at  a  given mount point.  The /etc/fstab file describes how
19       mount(8) should assemble a system's file name  hierarchy  from  various
20       independent  file  systems  (including  file  systems  exported  by NFS
21       servers).  Each line in the /etc/fstab file  describes  a  single  file
22       system,  its  mount  point, and a set of default mount options for that
23       mount point.
25       For NFS file system mounts, a line in the /etc/fstab file specifies the
26       server  name,  the path name of the exported server directory to mount,
27       the local directory that is the mount point, the type  of  file  system
28       that is being mounted, and a list of mount options that control the way
29       the filesystem is mounted and how the NFS client behaves when accessing
30       files on this mount point.  The fifth and sixth fields on each line are
31       not used by NFS, thus conventionally each contain the digit  zero.  For
32       example:
34               server:path   /mountpoint   fstype   option,option,...   0 0
36       The  server's  hostname  and  export pathname are separated by a colon,
37       while the mount options are separated by commas. The  remaining  fields
38       are separated by blanks or tabs.
40       The server's hostname can be an unqualified hostname, a fully qualified
41       domain name, a dotted quad IPv4 address, or an IPv6 address enclosed in
42       square  brackets.  Link-local and site-local IPv6 addresses must be ac‐
43       companied by an interface identifier.  See ipv6(7) for details on spec‐
44       ifying raw IPv6 addresses.
46       The  fstype  field  contains  "nfs".   Use  of  the  "nfs4"  fstype  in
47       /etc/fstab is deprecated.


50       Refer to mount(8) for a description of generic mount options  available
51       for  all file systems. If you do not need to specify any mount options,
52       use the generic option defaults in /etc/fstab.
54   Options supported by all versions
55       These options are valid to use with any NFS version.
57       nfsvers=n      The NFS protocol version  number  used  to  contact  the
58                      server's  NFS  service.   If the server does not support
59                      the requested version, the mount request fails.  If this
60                      option  is  not  specified, the client tries version 4.2
61                      first, then negotiates down until  it  finds  a  version
62                      supported by the server.
64       vers=n         This option is an alternative to the nfsvers option.  It
65                      is included for compatibility with other operating  sys‐
66                      tems
68       soft / hard    Determines the recovery behavior of the NFS client after
69                      an NFS request times out.  If neither option  is  speci‐
70                      fied  (or if the hard option is specified), NFS requests
71                      are retried indefinitely.  If the soft option is  speci‐
72                      fied, then the NFS client fails an NFS request after re‐
73                      trans retransmissions have been sent,  causing  the  NFS
74                      client to return an error to the calling application.
76                      NB:  A  so-called  "soft"  timeout can cause silent data
77                      corruption in certain cases. As such, use the  soft  op‐
78                      tion  only  when client responsiveness is more important
79                      than data integrity.  Using NFS over TCP  or  increasing
80                      the value of the retrans option may mitigate some of the
81                      risks of using the soft option.
83       softreval / nosoftreval
84                      In cases where the NFS server is down, it may be  useful
85                      to  allow  the  NFS client to continue to serve up paths
86                      and attributes from  cache  after  retrans  attempts  to
87                      revalidate that cache have timed out.  This may, for in‐
88                      stance, be helpful when trying to unmount  a  filesystem
89                      tree from a server that is permanently down.
91                      It  is possible to combine softreval with the soft mount
92                      option, in which case operations that cannot  be  served
93                      up  from  cache  will time out and return an error after
94                      retrans attempts. The combination with the default  hard
95                      mount option implies those uncached operations will con‐
96                      tinue to retry until a response  is  received  from  the
97                      server.
99                      Note: the default mount option is nosoftreval which dis‐
100                      allows fallback to cache when  revalidation  fails,  and
101                      instead  follows  the  behavior  dictated by the hard or
102                      soft mount option.
104       intr / nointr  This option is provided for backward compatibility.   It
105                      is ignored after kernel 2.6.25.
107       timeo=n        The  time  in  deciseconds  (tenths of a second) the NFS
108                      client waits for a response before it retries an NFS re‐
109                      quest.
111                      For NFS over TCP the default timeo value is 600 (60 sec‐
112                      onds).  The NFS client performs  linear  backoff:  After
113                      each retransmission the timeout is increased by timeo up
114                      to the maximum of 600 seconds.
116                      However, for NFS over UDP, the client uses  an  adaptive
117                      algorithm  to  estimate an appropriate timeout value for
118                      frequently used request types (such as  READ  and  WRITE
119                      requests),  but  uses the timeo setting for infrequently
120                      used request types (such as FSINFO  requests).   If  the
121                      timeo option is not specified, infrequently used request
122                      types are retried after 1.1  seconds.   After  each  re‐
123                      transmission,  the  NFS  client  doubles the timeout for
124                      that request, up to a maximum timeout length of 60  sec‐
125                      onds.
127       retrans=n      The number of times the NFS client retries a request be‐
128                      fore it attempts further recovery action. If the retrans
129                      option  is  not specified, the NFS client tries each UDP
130                      request three times and each TCP request twice.
132                      The NFS client generates a "server not responding"  mes‐
133                      sage after retrans retries, then attempts further recov‐
134                      ery (depending on whether the hard mount  option  is  in
135                      effect).
137       rsize=n        The maximum number of bytes in each network READ request
138                      that the NFS client can receive when reading data from a
139                      file  on an NFS server.  The actual data payload size of
140                      each NFS READ request is equal to or  smaller  than  the
141                      rsize setting. The largest read payload supported by the
142                      Linux NFS client is 1,048,576 bytes (one megabyte).
144                      The rsize value is a positive integral multiple of 1024.
145                      Specified rsize values lower than 1024 are replaced with
146                      4096; values  larger  than  1048576  are  replaced  with
147                      1048576.  If  a  specified value is within the supported
148                      range but not a multiple of 1024, it is rounded down  to
149                      the nearest multiple of 1024.
151                      If  an rsize value is not specified, or if the specified
152                      rsize value is  larger  than  the  maximum  that  either
153                      client  or server can support, the client and server ne‐
154                      gotiate the largest rsize value that they can both  sup‐
155                      port.
157                      The rsize mount option as specified on the mount(8) com‐
158                      mand line appears in the /etc/mtab  file.  However,  the
159                      effective  rsize  value  negotiated  by  the  client and
160                      server is reported in the /proc/mounts file.
162       wsize=n        The maximum number of bytes per  network  WRITE  request
163                      that the NFS client can send when writing data to a file
164                      on an NFS server. The actual data payload size  of  each
165                      NFS  WRITE request is equal to or smaller than the wsize
166                      setting. The largest  write  payload  supported  by  the
167                      Linux NFS client is 1,048,576 bytes (one megabyte).
169                      Similar  to  rsize , the wsize value is a positive inte‐
170                      gral multiple of 1024.   Specified  wsize  values  lower
171                      than  1024  are  replaced  with 4096; values larger than
172                      1048576 are replaced with 1048576. If a specified  value
173                      is  within  the  supported  range  but not a multiple of
174                      1024, it is rounded down  to  the  nearest  multiple  of
175                      1024.
177                      If  a  wsize value is not specified, or if the specified
178                      wsize value is  larger  than  the  maximum  that  either
179                      client  or server can support, the client and server ne‐
180                      gotiate the largest wsize value that they can both  sup‐
181                      port.
183                      The wsize mount option as specified on the mount(8) com‐
184                      mand line appears in the /etc/mtab  file.  However,  the
185                      effective  wsize  value  negotiated  by  the  client and
186                      server is reported in the /proc/mounts file.
188       ac / noac      Selects whether the client may cache file attributes. If
189                      neither option is specified (or if ac is specified), the
190                      client caches file attributes.
192                      To improve  performance,  NFS  clients  cache  file  at‐
193                      tributes.  Every  few  seconds, an NFS client checks the
194                      server's version of each file's attributes for  updates.
195                      Changes  that  occur on the server in those small inter‐
196                      vals remain  undetected  until  the  client  checks  the
197                      server  again.  The  noac  option  prevents clients from
198                      caching file attributes so that  applications  can  more
199                      quickly detect file changes on the server.
201                      In  addition  to preventing the client from caching file
202                      attributes, the noac option forces application writes to
203                      become  synchronous  so that local changes to a file be‐
204                      come visible on the server immediately.  That way, other
205                      clients can quickly detect recent writes when they check
206                      the file's attributes.
208                      Using the noac option provides greater  cache  coherence
209                      among  NFS  clients accessing the same files, but it ex‐
210                      tracts a significant performance penalty.  As such,  ju‐
211                      dicious  use of file locking is encouraged instead.  The
212                      DATA AND METADATA COHERENCE section contains a  detailed
213                      discussion of these trade-offs.
215       acregmin=n     The minimum time (in seconds) that the NFS client caches
216                      attributes of a regular file before  it  requests  fresh
217                      attribute  information from a server.  If this option is
218                      not specified, the NFS client uses a  3-second  minimum.
219                      See  the  DATA AND METADATA COHERENCE section for a full
220                      discussion of attribute caching.
222       acregmax=n     The maximum time (in seconds) that the NFS client caches
223                      attributes  of  a  regular file before it requests fresh
224                      attribute information from a server.  If this option  is
225                      not  specified, the NFS client uses a 60-second maximum.
226                      See the DATA AND METADATA COHERENCE section for  a  full
227                      discussion of attribute caching.
229       acdirmin=n     The minimum time (in seconds) that the NFS client caches
230                      attributes of a directory before it requests  fresh  at‐
231                      tribute  information  from  a server.  If this option is
232                      not specified, the NFS client uses a 30-second  minimum.
233                      See  the  DATA AND METADATA COHERENCE section for a full
234                      discussion of attribute caching.
236       acdirmax=n     The maximum time (in seconds) that the NFS client caches
237                      attributes  of  a directory before it requests fresh at‐
238                      tribute information from a server.  If  this  option  is
239                      not  specified, the NFS client uses a 60-second maximum.
240                      See the DATA AND METADATA COHERENCE section for  a  full
241                      discussion of attribute caching.
243       actimeo=n      Using  actimeo sets all of acregmin, acregmax, acdirmin,
244                      and acdirmax to the same value.  If this option  is  not
245                      specified,  the NFS client uses the defaults for each of
246                      these options listed above.
248       bg / fg        Determines how the mount(8) command behaves  if  an  at‐
249                      tempt  to  mount  an export fails.  The fg option causes
250                      mount(8) to exit with an error status if any part of the
251                      mount  request  times  out  or  fails outright.  This is
252                      called a "foreground" mount, and is the default behavior
253                      if neither the fg nor bg mount option is specified.
255                      If  the  bg  option  is  specified, a timeout or failure
256                      causes the mount(8) command to fork a child  which  con‐
257                      tinues to attempt to mount the export.  The parent imme‐
258                      diately returns with a zero exit code.  This is known as
259                      a "background" mount.
261                      If  the  local  mount  point  directory  is missing, the
262                      mount(8) command acts as if the mount request timed out.
263                      This  permits  nested NFS mounts specified in /etc/fstab
264                      to proceed in any order  during  system  initialization,
265                      even  if some NFS servers are not yet available.  Alter‐
266                      natively these issues can be addressed  using  an  auto‐
267                      mounter (refer to automount(8) for details).
269       nconnect=n     When  using  a connection oriented protocol such as TCP,
270                      it may sometimes be advantageous to set up multiple con‐
271                      nections between the client and server. For instance, if
272                      your clients and/or servers are equipped  with  multiple
273                      network  interface  cards (NICs), using multiple connec‐
274                      tions to spread the load  may  improve  overall  perfor‐
275                      mance.   In  such  cases, the nconnect option allows the
276                      user to specify the number of connections that should be
277                      established  between the client and server up to a limit
278                      of 16.
280                      Note that the nconnect option may also be used  by  some
281                      pNFS drivers to decide how many connections to set up to
282                      the data servers.
284       max_connect=n  While nconnect option sets a limit on the number of con‐
285                      nections  that  can be established to a given server IP,
286                      max_connect option allows the user  to  specify  maximum
287                      number  of  connections to different server IPs that be‐
288                      long to the same NFSv4.1+ server (session trunkable con‐
289                      nections)  up  to  a  limit of 16. When client discovers
290                      that it established a client ID to an  already  existing
291                      server,  instead  of  dropping the newly created network
292                      transport, the client will add this  new  connection  to
293                      the list of available transports for that RPC client.
295       rdirplus / nordirplus
296                      Selects  whether  to  use  NFS  v3 or v4 READDIRPLUS re‐
297                      quests.  If this option is not specified, the NFS client
298                      uses READDIRPLUS requests on NFS v3 or v4 mounts to read
299                      small directories.  Some applications perform better  if
300                      the  client  uses only READDIR requests for all directo‐
301                      ries.
303       retry=n        The number of minutes that the mount(8) command  retries
304                      an  NFS  mount operation in the foreground or background
305                      before giving up.  If this option is not specified,  the
306                      default  value  for  foreground mounts is 2 minutes, and
307                      the default value for background mounts is 10000 minutes
308                      (80  minutes  shy  of  one week).  If a value of zero is
309                      specified, the mount(8) command exits immediately  after
310                      the first failure.
312                      Note  that  this  only affects how many retries are made
313                      and doesn't affect the delay caused by each retry.   For
314                      UDP  each  retry  takes the time determined by the timeo
315                      and retrans options, which by default will  be  about  7
316                      seconds.   For  TCP the default is 3 minutes, but system
317                      TCP connection timeouts will sometimes limit the timeout
318                      of each retransmission to around 2 minutes.
320       sec=flavors    A  colon-separated  list of one or more security flavors
321                      to use for accessing files on the mounted export. If the
322                      server  does not support any of these flavors, the mount
323                      operation fails.  If sec= is not specified,  the  client
324                      attempts  to find a security flavor that both the client
325                      and the server supports.  Valid flavors are  none,  sys,
326                      krb5, krb5i, and krb5p.  Refer to the SECURITY CONSIDER‐
327                      ATIONS section for details.
329       sharecache / nosharecache
330                      Determines how the client's  data  cache  and  attribute
331                      cache are shared when mounting the same export more than
332                      once concurrently.  Using the same cache reduces  memory
333                      requirements  on  the client and presents identical file
334                      contents to applications when the same  remote  file  is
335                      accessed via different mount points.
337                      If neither option is specified, or if the sharecache op‐
338                      tion is specified, then a single cache is used  for  all
339                      mount  points  that  access  the  same  export.   If the
340                      nosharecache option is specified, then that mount  point
341                      gets  a unique cache.  Note that when data and attribute
342                      caches are shared, the  mount  options  from  the  first
343                      mount point take effect for subsequent concurrent mounts
344                      of the same export.
346                      As of kernel 2.6.18, the behavior specified by  noshare‐
347                      cache  is  legacy caching behavior. This is considered a
348                      data risk since multiple cached copies of the same  file
349                      on  the  same  client can become out of sync following a
350                      local update of one of the copies.
352       resvport / noresvport
353                      Specifies whether the NFS client should use a privileged
354                      source  port  when  communicating with an NFS server for
355                      this mount point.  If this option is not  specified,  or
356                      the  resvport option is specified, the NFS client uses a
357                      privileged source port.  If  the  noresvport  option  is
358                      specified,  the  NFS client uses a non-privileged source
359                      port.  This option is supported in  kernels  2.6.28  and
360                      later.
362                      Using  non-privileged  source  ports  helps increase the
363                      maximum number of NFS mount points allowed on a  client,
364                      but  NFS  servers must be configured to allow clients to
365                      connect via non-privileged source ports.
367                      Refer to the SECURITY CONSIDERATIONS section for  impor‐
368                      tant details.
370       lookupcache=mode
371                      Specifies  how the kernel manages its cache of directory
372                      entries for a given mount point.  mode  can  be  one  of
373                      all,  none,  pos, or positive.  This option is supported
374                      in kernels 2.6.28 and later.
376                      The Linux NFS client caches the result of all NFS LOOKUP
377                      requests.   If  the  requested directory entry exists on
378                      the server, the result is referred to as  positive.   If
379                      the  requested  directory  entry  does  not exist on the
380                      server, the result is referred to as negative.
382                      If this option is not specified, or if all is specified,
383                      the client assumes both types of directory cache entries
384                      are valid until  their  parent  directory's  cached  at‐
385                      tributes expire.
387                      If pos or positive is specified, the client assumes pos‐
388                      itive entries are valid until their  parent  directory's
389                      cached  attributes  expire, but always revalidates nega‐
390                      tive entires before an application can use them.
392                      If none is specified, the client revalidates both  types
393                      of directory cache entries before an application can use
394                      them.  This permits quick detection of files  that  were
395                      created  or removed by other clients, but can impact ap‐
396                      plication and server performance.
398                      The DATA AND METADATA COHERENCE section contains  a  de‐
399                      tailed discussion of these trade-offs.
401       fsc / nofsc    Enable/Disables  the  cache of (read-only) data pages to
402                      the  local  disk  using  the  FS-Cache   facility.   See
403                      cachefilesd(8)       and      <kernel_source>/Documenta‐
404                      tion/filesystems/caching for detail on how to  configure
405                      the FS-Cache facility.  Default value is nofsc.
407       sloppy         The  sloppy  option  is  an  alternative  to  specifying
408                      mount.nfs -s option.
411   Options for NFS versions 2 and 3 only
412       Use these options, along with the options in the above subsection,  for
413       NFS versions 2 and 3 only.
415       proto=netid    The  netid determines the transport that is used to com‐
416                      municate with the NFS  server.   Available  options  are
417                      udp,  udp6, tcp, tcp6, rdma, and rdma6.  Those which end
418                      in 6 use IPv6 addresses and are only available  if  sup‐
419                      port for TI-RPC is built in. Others use IPv4 addresses.
421                      Each  transport  protocol uses different default retrans
422                      and timeo settings.  Refer to the description  of  these
423                      two mount options for details.
425                      In  addition to controlling how the NFS client transmits
426                      requests to the server, this mount option also  controls
427                      how  the mount(8) command communicates with the server's
428                      rpcbind and mountd services.  Specifying  a  netid  that
429                      uses  TCP  forces  all traffic from the mount(8) command
430                      and the NFS client to use TCP.  Specifying a netid  that
431                      uses UDP forces all traffic types to use UDP.
433                      Before  using NFS over UDP, refer to the TRANSPORT METH‐
434                      ODS section.
436                      If the proto mount option is not specified, the mount(8)
437                      command  discovers  which  protocols the server supports
438                      and chooses an appropriate transport for  each  service.
439                      Refer to the TRANSPORT METHODS section for more details.
441       udp            The   udp   option   is  an  alternative  to  specifying
442                      proto=udp.  It is included for compatibility with  other
443                      operating systems.
445                      Before  using NFS over UDP, refer to the TRANSPORT METH‐
446                      ODS section.
448       tcp            The  tcp  option  is  an   alternative   to   specifying
449                      proto=tcp.   It is included for compatibility with other
450                      operating systems.
452       rdma           The  rdma  option  is  an  alternative   to   specifying
453                      proto=rdma.
455       port=n         The  numeric value of the server's NFS service port.  If
456                      the server's NFS service is not available on the  speci‐
457                      fied port, the mount request fails.
459                      If  this  option  is  not specified, or if the specified
460                      port value is 0, then the NFS client uses the  NFS  ser‐
461                      vice port number advertised by the server's rpcbind ser‐
462                      vice.  The mount request fails if the  server's  rpcbind
463                      service  is  not  available, the server's NFS service is
464                      not registered with its rpcbind service, or the server's
465                      NFS service is not available on the advertised port.
467       mountport=n    The  numeric  value of the server's mountd port.  If the
468                      server's mountd service is not available on  the  speci‐
469                      fied port, the mount request fails.
471                      If  this  option  is  not specified, or if the specified
472                      port value is 0, then  the  mount(8)  command  uses  the
473                      mountd  service  port  number advertised by the server's
474                      rpcbind  service.   The  mount  request  fails  if   the
475                      server's  rpcbind service is not available, the server's
476                      mountd service is not registered with its  rpcbind  ser‐
477                      vice, or the server's mountd service is not available on
478                      the advertised port.
480                      This option can be used  when  mounting  an  NFS  server
481                      through a firewall that blocks the rpcbind protocol.
483       mountproto=netid
484                      The  transport  the NFS client uses to transmit requests
485                      to the NFS server's mountd service when performing  this
486                      mount  request,  and  when  later  unmounting this mount
487                      point.
489                      netid may be one of udp, and tcp which use IPv4  address
490                      or, if TI-RPC is built into the mount.nfs command, udp6,
491                      and tcp6 which use IPv6 addresses.
493                      This option can be used  when  mounting  an  NFS  server
494                      through  a  firewall that blocks a particular transport.
495                      When used in combination with the proto option,  differ‐
496                      ent  transports for mountd requests and NFS requests can
497                      be specified.  If the server's  mountd  service  is  not
498                      available via the specified transport, the mount request
499                      fails.
501                      Refer to the TRANSPORT METHODS section for more  on  how
502                      the  mountproto  mount  option  interacts with the proto
503                      mount option.
505       mounthost=name The hostname of the host running mountd.  If this option
506                      is  not specified, the mount(8) command assumes that the
507                      mountd service runs on the same host as the NFS service.
509       mountvers=n    The RPC version number  used  to  contact  the  server's
510                      mountd.   If  this  option  is not specified, the client
511                      uses a version number appropriate to the  requested  NFS
512                      version.   This  option is useful when multiple NFS ser‐
513                      vices are running on the same remote server host.
515       namlen=n       The maximum length  of  a  pathname  component  on  this
516                      mount.   If  this  option  is not specified, the maximum
517                      length is negotiated with the  server.  In  most  cases,
518                      this maximum length is 255 characters.
520                      Some early versions of NFS did not support this negotia‐
521                      tion.  Using this option ensures  that  pathconf(3)  re‐
522                      ports  the  proper  maximum component length to applica‐
523                      tions in such cases.
525       lock / nolock  Selects whether to use the NLM sideband protocol to lock
526                      files on the server.  If neither option is specified (or
527                      if lock is specified), NLM  locking  is  used  for  this
528                      mount point.  When using the nolock option, applications
529                      can lock files, but such locks  provide  exclusion  only
530                      against  other  applications running on the same client.
531                      Remote applications are not affected by these locks.
533                      NLM locking must be disabled with the nolock option when
534                      using NFS to mount /var because /var contains files used
535                      by the NLM implementation on Linux.   Using  the  nolock
536                      option  is  also  required  when mounting exports on NFS
537                      servers that do not support the NLM protocol.
539       cto / nocto    Selects whether to use close-to-open cache coherence se‐
540                      mantics.   If  neither option is specified (or if cto is
541                      specified), the client uses close-to-open  cache  coher‐
542                      ence  semantics.  If  the nocto option is specified, the
543                      client uses a non-standard heuristic to  determine  when
544                      files on the server have changed.
546                      Using the nocto option may improve performance for read-
547                      only mounts, but should be used only if the data on  the
548                      server changes only occasionally.  The DATA AND METADATA
549                      COHERENCE section discusses the behavior of this  option
550                      in more detail.
552       acl / noacl    Selects  whether  to use the NFSACL sideband protocol on
553                      this mount point.  The NFSACL  sideband  protocol  is  a
554                      proprietary protocol implemented in Solaris that manages
555                      Access Control Lists. NFSACL was never made  a  standard
556                      part of the NFS protocol specification.
558                      If  neither  acl  nor noacl option is specified, the NFS
559                      client negotiates with the server to see if  the  NFSACL
560                      protocol  is  supported,  and uses it if the server sup‐
561                      ports it.  Disabling the NFSACL sideband protocol may be
562                      necessary  if  the  negotiation  causes  problems on the
563                      client or server.  Refer to the SECURITY  CONSIDERATIONS
564                      section for more details.
566       local_lock=mechanism
567                      Specifies  whether  to use local locking for any or both
568                      of the flock and the POSIX locking  mechanisms.   mecha‐
569                      nism can be one of all, flock, posix, or none.  This op‐
570                      tion is supported in kernels 2.6.37 and later.
572                      The Linux NFS client provides a way to make locks local.
573                      This  means,  the  applications can lock files, but such
574                      locks provide exclusion only against other  applications
575                      running  on the same client. Remote applications are not
576                      affected by these locks.
578                      If this option is not specified, or if  none  is  speci‐
579                      fied, the client assumes that the locks are not local.
581                      If  all is specified, the client assumes that both flock
582                      and POSIX locks are local.
584                      If flock is specified,  the  client  assumes  that  only
585                      flock  locks are local and uses NLM sideband protocol to
586                      lock files when POSIX locks are used.
588                      If posix is specified, the  client  assumes  that  POSIX
589                      locks  are  local and uses NLM sideband protocol to lock
590                      files when flock locks are used.
592                      To support legacy flock behavior similar to that of  NFS
593                      clients < 2.6.12, use 'local_lock=flock'. This option is
594                      required when exporting NFS mounts via  Samba  as  Samba
595                      maps  Windows  share  mode  locks  as  flock.  Since NFS
596                      clients > 2.6.12  implement  flock  by  emulating  POSIX
597                      locks, this will result in conflicting locks.
599                      NOTE:  When used together, the 'local_lock' mount option
600                      will be overridden by 'nolock'/'lock' mount option.
602   Options for NFS version 4 only
603       Use these options, along with  the  options  in  the  first  subsection
604       above, for NFS version 4.0 and newer.
606       proto=netid    The  netid determines the transport that is used to com‐
607                      municate with the NFS  server.   Supported  options  are
608                      tcp, tcp6, rdma, and rdma6.  tcp6 use IPv6 addresses and
609                      is only available if support for  TI-RPC  is  built  in.
610                      Both others use IPv4 addresses.
612                      All  NFS  version 4 servers are required to support TCP,
613                      so if this mount option is not specified, the  NFS  ver‐
614                      sion  4  client  uses  the  TCP  protocol.  Refer to the
615                      TRANSPORT METHODS section for more details.
617       minorversion=n Specifies the protocol minor version number.  NFSv4  in‐
618                      troduces "minor versioning," where NFS protocol enhance‐
619                      ments can be introduced without bumping the NFS protocol
620                      version number.  Before kernel 2.6.38, the minor version
621                      is always zero, and this option is not recognized.   Af‐
622                      ter  this  kernel, specifying "minorversion=1" enables a
623                      number of advanced features, such as NFSv4 sessions.
625                      Recent kernels allow the minor version to  be  specified
626                      using   the   vers=  option.   For  example,  specifying
627                      vers=4.1 is  the  same  as  specifying  vers=4,minorver‐
628                      sion=1.
630       port=n         The  numeric value of the server's NFS service port.  If
631                      the server's NFS service is not available on the  speci‐
632                      fied port, the mount request fails.
634                      If  this  mount  option is not specified, the NFS client
635                      uses the standard NFS port number of 2049 without  first
636                      checking  the  server's rpcbind service.  This allows an
637                      NFS version 4 client to contact an NFS version 4  server
638                      through a firewall that may block rpcbind requests.
640                      If  the  specified  port value is 0, then the NFS client
641                      uses the NFS  service  port  number  advertised  by  the
642                      server's  rpcbind  service.   The mount request fails if
643                      the server's  rpcbind  service  is  not  available,  the
644                      server's  NFS service is not registered with its rpcbind
645                      service, or the server's NFS service is not available on
646                      the advertised port.
648       cto / nocto    Selects whether to use close-to-open cache coherence se‐
649                      mantics for NFS directories on  this  mount  point.   If
650                      neither  cto  nor  nocto is specified, the default is to
651                      use close-to-open cache coherence semantics for directo‐
652                      ries.
654                      File  data  caching behavior is not affected by this op‐
655                      tion.  The DATA AND METADATA COHERENCE section discusses
656                      the behavior of this option in more detail.
658       clientaddr=n.n.n.n
660       clientaddr=n:n:...:n
661                      Specifies  a  single IPv4 address (in dotted-quad form),
662                      or a non-link-local IPv6 address, that  the  NFS  client
663                      advertises  to  allow servers to perform NFS version 4.0
664                      callback requests against files on this mount point.  If
665                      the   server is unable to establish callback connections
666                      to clients, performance  may  degrade,  or  accesses  to
667                      files  may  temporarily  hang.   Can  specify a value of
668                      IPv4_ANY ( or equivalent IPv6 any address  which
669                      will  signal to the NFS server that this NFS client does
670                      not want delegations.
672                      If this option is not specified,  the  mount(8)  command
673                      attempts to discover an appropriate callback address au‐
674                      tomatically.  The automatic  discovery  process  is  not
675                      perfect,  however.   In  the presence of multiple client
676                      network interfaces, special routing policies, or  atypi‐
677                      cal  network  topologies,  the  exact address to use for
678                      callbacks may be nontrivial to determine.
680                      NFS protocol versions 4.1 and 4.2 use the  client-estab‐
681                      lished  TCP  connection for callback requests, so do not
682                      require the server to connect to the client.   This  op‐
683                      tion is therefore only affect NFS version 4.0 mounts.
685       migration / nomigration
686                      Selects whether the client uses an identification string
687                      that is compatible with NFSv4 Transparent  State  Migra‐
688                      tion (TSM).  If the mounted server supports NFSv4 migra‐
689                      tion with TSM, specify the migration option.
691                      Some server features misbehave in the face of  a  migra‐
692                      tion-compatible  identification string.  The nomigration
693                      option retains the use of a traditional client  indenti‐
694                      fication  string  which  is  compatible  with legacy NFS
695                      servers.  This is also the behavior if neither option is
696                      specified.  A client's open and lock state cannot be mi‐
697                      grated transparently when it  identifies  itself  via  a
698                      traditional identification string.
700                      This  mount  option  has no effect with NFSv4 minor ver‐
701                      sions newer than zero, which always  use  TSM-compatible
702                      client identification strings.


705       The  nfs4 file system type is an old syntax for specifying NFSv4 usage.
706       It can still be used with all NFSv4-specific and  common  options,  ex‐
707       cepted the nfsvers mount option.


710       If  the  mount command is configured to do so, all of the mount options
711       described in the  previous  section  can  also  be  configured  in  the
712       /etc/nfsmount.conf file. See nfsmount.conf(5) for details.


715       mount  option.   To  mount using NFS version 3, use the nfs file system
716       type and specify the nfsvers=3 mount option.  To mount using  NFS  ver‐
717       sion  4,  use either the nfs file system type, with the nfsvers=4 mount
718       option, or the nfs4 file system type.
720       The following example from an /etc/fstab file causes the mount  command
721       to negotiate reasonable defaults for NFS behavior.
723               server:/export  /mnt  nfs   defaults                      0 0
725       This  example shows how to mount using NFS version 4 over TCP with Ker‐
726       beros 5 mutual authentication.
728               server:/export  /mnt  nfs4  sec=krb5                      0 0
730       This example shows how to mount using NFS version 4 over TCP with  Ker‐
731       beros 5 privacy or data integrity mode.
733               server:/export  /mnt  nfs4  sec=krb5p:krb5i               0 0
735       This example can be used to mount /usr over NFS.
737               server:/export  /usr  nfs   ro,nolock,nocto,actimeo=3600  0 0
739       This example shows how to mount an NFS server using a raw IPv6 link-lo‐
740       cal address.
742               [fe80::215:c5ff:fb3e:e2b1%eth0]:/export /mnt nfs defaults 0 0


745       NFS clients send requests to NFS servers via Remote Procedure Calls, or
746       RPCs.  The RPC client discovers remote service endpoints automatically,
747       handles per-request authentication, adjusts request parameters for dif‐
748       ferent  byte  endianness on client and server, and retransmits requests
749       that may have been lost by the network or  server.   RPC  requests  and
750       replies flow over a network transport.
752       In most cases, the mount(8) command, NFS client, and NFS server can au‐
753       tomatically negotiate proper transport and data transfer size  settings
754       for  a  mount  point.  In some cases, however, it pays to specify these
755       settings explicitly using mount options.
757       Traditionally, NFS clients  used  the  UDP  transport  exclusively  for
758       transmitting requests to servers.  Though its implementation is simple,
759       NFS over UDP has many limitations that  prevent  smooth  operation  and
760       good  performance  in some common deployment environments.  Even an in‐
761       significant packet loss rate results in the loss of whole NFS requests;
762       as  such, retransmit timeouts are usually in the subsecond range to al‐
763       low clients to recover quickly from dropped requests, but this can  re‐
764       sult in extraneous network traffic and server load.
766       However,  UDP  can be quite effective in specialized settings where the
767       networks MTU is large relative to NFSs data transfer size (such as net‐
768       work environments that enable jumbo Ethernet frames).  In such environ‐
769       ments, trimming the rsize and wsize settings so that each NFS  read  or
770       write  request  fits in just a few network frames (or even in  a single
771       frame) is advised.  This reduces the probability that  the  loss  of  a
772       single  MTU-sized  network frame results in the loss of an entire large
773       read or write request.
775       TCP is the default transport protocol used for all modern NFS implemen‐
776       tations.  It performs well in almost every conceivable network environ‐
777       ment and provides excellent guarantees against data  corruption  caused
778       by  network  unreliability.   TCP is often a requirement for mounting a
779       server through a network firewall.
781       Under normal circumstances, networks drop packets much more  frequently
782       than  NFS  servers  drop  requests.   As such, an aggressive retransmit
783       timeout  setting for NFS over TCP is unnecessary. Typical timeout  set‐
784       tings  for  NFS  over  TCP are between one and ten minutes.  After  the
785       client exhausts its retransmits (the value of  the  retrans  mount  op‐
786       tion), it assumes a network partition has occurred, and attempts to re‐
787       connect to the server on a fresh socket. Since TCP itself makes network
788       data  transfer  reliable,  rsize and wsize can safely be allowed to de‐
789       fault to the largest values supported by both client and server,  inde‐
790       pendent of the network's MTU size.
792   Using the mountproto mount option
793       This  section  applies only to NFS version 3 mounts since NFS version 4
794       does not use a separate protocol for mount requests.
796       The Linux NFS client can use a different transport  for  contacting  an
797       NFS server's rpcbind service, its mountd service, its Network Lock Man‐
798       ager (NLM) service, and its NFS service.  The exact transports employed
799       by the Linux NFS client for each mount point depends on the settings of
800       the transport mount options, which include proto, mountproto, udp,  and
801       tcp.
803       The  client sends Network Status Manager (NSM) notifications via UDP no
804       matter what transport options are specified, but listens for server NSM
805       notifications  on  both  UDP and TCP.  The NFS Access Control List (NF‐
806       SACL) protocol shares the same transport as the main NFS service.
808       If no transport options are specified, the Linux NFS client uses UDP to
809       contact the server's mountd service, and TCP to contact its NLM and NFS
810       services by default.
812       If the server does not support these transports for these services, the
813       mount(8)  command  attempts  to  discover what the server supports, and
814       then retries the mount request once using  the  discovered  transports.
815       If  the server does not advertise any transport supported by the client
816       or is misconfigured, the mount request fails.  If the bg option  is  in
817       effect,  the  mount command backgrounds itself and continues to attempt
818       the specified mount request.
820       When the proto option, the udp option, or the tcp option  is  specified
821       but  the  mountproto  option is not, the specified transport is used to
822       contact both the server's mountd service and for the NLM and  NFS  ser‐
823       vices.
825       If the mountproto option is specified but none of the proto, udp or tcp
826       options are specified, then the specified transport  is  used  for  the
827       initial mountd request, but the mount command attempts to discover what
828       the server supports for the NFS protocol, preferring TCP if both trans‐
829       ports are supported.
831       If both the mountproto and proto (or udp or tcp) options are specified,
832       then the transport specified by the mountproto option is used  for  the
833       initial mountd request, and the transport specified by the proto option
834       (or the udp or tcp options) is used for NFS, no matter what order these
835       options  appear.   No automatic service discovery is performed if these
836       options are specified.
838       If any of the proto, udp, tcp, or mountproto options are specified more
839       than  once on the same mount command line, then the value of the right‐
840       most instance of each of these options takes effect.
842   Using NFS over UDP on high-speed links
843       Using NFS over UDP on high-speed links such as Gigabit can cause silent
844       data corruption.
846       The  problem  can be triggered at high loads, and is caused by problems
847       in IP fragment reassembly. NFS read and writes typically  transmit  UDP
848       packets of 4 Kilobytes or more, which have to be broken up into several
849       fragments in order to be sent over  the  Ethernet  link,  which  limits
850       packets  to  1500 bytes by default. This process happens at the IP net‐
851       work layer and is called fragmentation.
853       In order to identify fragments that belong together, IP assigns a 16bit
854       IP  ID  value  to  each  packet;  fragments generated from the same UDP
855       packet will have the same IP ID.  The  receiving  system  will  collect
856       these  fragments and combine them to form the original UDP packet. This
857       process is called reassembly. The default timeout for packet reassembly
858       is 30 seconds; if the network stack does not receive all fragments of a
859       given packet within this interval, it assumes the  missing  fragment(s)
860       got lost and discards those it already received.
862       The  problem  this creates over high-speed links is that it is possible
863       to send more than 65536 packets within 30 seconds. In fact, with  heavy
864       NFS  traffic  one can observe that the IP IDs repeat after about 5 sec‐
865       onds.
867       This has serious effects on reassembly: if one fragment gets lost,  an‐
868       other fragment from a different packet but with the same IP ID will ar‐
869       rive within the 30 second timeout, and the network stack  will  combine
870       these  fragments to form a new packet. Most of the time, network layers
871       above IP will detect this mismatched reassembly - in the case  of  UDP,
872       the  UDP  checksum,  which  is a 16 bit checksum over the entire packet
873       payload, will usually not match, and UDP will discard the bad packet.
875       However, the UDP checksum is 16 bit only, so there is a chance of 1  in
876       65536  that it will match even if the packet payload is completely ran‐
877       dom (which very often isn't the case). If that is the case, silent data
878       corruption will occur.
880       This potential should be taken seriously, at least on Gigabit Ethernet.
881       Network speeds of 100Mbit/s should be considered less problematic,  be‐
882       cause  with  most  traffic  patterns  IP  ID wrap around will take much
883       longer than 30 seconds.
885       It is therefore strongly recommended to use NFS over TCP  where  possi‐
886       ble, since TCP does not perform fragmentation.
888       If  you absolutely have to use NFS over UDP over Gigabit Ethernet, some
889       steps can be taken to mitigate the problem and reduce  the  probability
890       of corruption:
892       Jumbo frames:  Many  Gigabit  network cards are capable of transmitting
893                      frames bigger than the 1500 byte  limit  of  traditional
894                      Ethernet,  typically  9000  bytes. Using jumbo frames of
895                      9000 bytes will allow you to run NFS over UDP at a  page
896                      size  of  8K  without  fragmentation. Of course, this is
897                      only feasible if all  involved  stations  support  jumbo
898                      frames.
900                      To  enable  a machine to send jumbo frames on cards that
901                      support it, it is sufficient to configure the  interface
902                      for a MTU value of 9000.
904       Lower reassembly timeout:
905                      By  lowering this timeout below the time it takes the IP
906                      ID counter to wrap around, incorrect reassembly of frag‐
907                      ments  can  be prevented as well. To do so, simply write
908                      the  new  timeout  value  (in  seconds)  to   the   file
909                      /proc/sys/net/ipv4/ipfrag_time.
911                      A value of 2 seconds will greatly reduce the probability
912                      of IPID clashes on a single Gigabit  link,  while  still
913                      allowing  for  a reasonable timeout when receiving frag‐
914                      mented traffic from distant peers.


917       Some modern cluster file systems provide perfect cache coherence  among
918       their  clients.  Perfect cache coherence among disparate NFS clients is
919       expensive to achieve, especially on wide area networks.  As  such,  NFS
920       settles  for  weaker cache coherence that satisfies the requirements of
921       most file sharing types.
923   Close-to-open cache consistency
924       Typically file sharing is completely sequential.  First client A  opens
925       a  file,  writes  something to it, then closes it.  Then client B opens
926       the same file, and reads the changes.
928       When an application opens a file stored on an NFS version 3 server, the
929       NFS  client  checks that the file exists on the server and is permitted
930       to the opener by sending a GETATTR or ACCESS request.  The  NFS  client
931       sends  these  requests regardless of the freshness of the file's cached
932       attributes.
934       When the application closes the file, the NFS client  writes  back  any
935       pending  changes  to  the  file  so  that  the next opener can view the
936       changes.  This also gives the NFS client an opportunity to report write
937       errors to the application via the return code from close(2).
939       The behavior of checking at open time and flushing at close time is re‐
940       ferred to as close-to-open cache consistency, or CTO.  It can  be  dis‐
941       abled for an entire mount point using the nocto mount option.
943   Weak cache consistency
944       There  are  still  opportunities  for  a client's data cache to contain
945       stale data.  The NFS version 3 protocol introduced "weak cache  consis‐
946       tency" (also known as WCC) which provides a way of efficiently checking
947       a file's attributes before and after a single request.  This  allows  a
948       client  to  help  identify  changes  that could have been made by other
949       clients.
951       When a client is using many concurrent operations that update the  same
952       file  at the same time (for example, during asynchronous write behind),
953       it is still difficult to tell whether it was that client's  updates  or
954       some other client's updates that altered the file.
956   Attribute caching
957       Use  the  noac  mount option to achieve attribute cache coherence among
958       multiple clients.  Almost every file system operation checks  file  at‐
959       tribute  information.   The  client keeps this information cached for a
960       period of time to reduce network and server load.  When noac is in  ef‐
961       fect,  a  client's  file attribute cache is disabled, so each operation
962       that needs to check a file's attributes is forced to  go  back  to  the
963       server.   This  permits a client to see changes to a file very quickly,
964       at the cost of many extra network operations.
966       Be careful not to confuse the noac option with "no data caching."   The
967       noac  mount  option prevents the client from caching file metadata, but
968       there are still races that may result in data cache incoherence between
969       client and server.
971       The  NFS  protocol  is not designed to support true cluster file system
972       cache coherence without some type of application serialization.  If ab‐
973       solute  cache  coherence among clients is required, applications should
974       use file locking. Alternatively, applications can also open their files
975       with the O_DIRECT flag to disable data caching entirely.
977   File timestamp maintenance
978       NFS  servers are responsible for managing file and directory timestamps
979       (atime, ctime, and mtime).  When a file is accessed or  updated  on  an
980       NFS  server,  the file's timestamps are updated just like they would be
981       on a filesystem local to an application.
983       NFS clients cache file  attributes,  including  timestamps.   A  file's
984       timestamps are updated on NFS clients when its attributes are retrieved
985       from the NFS server.  Thus there may be some delay before timestamp up‐
986       dates on an NFS server appear to applications on NFS clients.
988       To  comply with the POSIX filesystem standard, the Linux NFS client re‐
989       lies on NFS servers to keep a file's mtime and ctime  timestamps  prop‐
990       erly  up  to  date.  It does this by flushing local data changes to the
991       server before reporting mtime to applications via system calls such  as
992       stat(2).
994       The  Linux  client  handles  atime  updates more loosely, however.  NFS
995       clients maintain good performance by caching data, but that means  that
996       application  reads,  which  normally update atime, are not reflected to
997       the server where a file's atime is actually maintained.
999       Because of this caching behavior, the Linux NFS client does not support
1000       generic atime-related mount options.  See mount(8) for details on these
1001       options.
1003       In particular, the atime/noatime, diratime/nodiratime, relatime/norela‐
1004       time, and strictatime/nostrictatime mount options have no effect on NFS
1005       mounts.
1007       /proc/mounts may report that the relatime mount option is  set  on  NFS
1008       mounts,  but  in fact the atime semantics are always as described here,
1009       and are not like relatime semantics.
1011   Directory entry caching
1012       The Linux NFS client caches the result of all NFS LOOKUP requests.   If
1013       the  requested  directory entry exists on the server, the result is re‐
1014       ferred to as a positive lookup result.  If the requested directory  en‐
1015       try does not exist on the server (that is, the server returned ENOENT),
1016       the result is referred to as negative lookup result.
1018       To detect when directory entries have been  added  or  removed  on  the
1019       server,  the  Linux  NFS  client  watches  a directory's mtime.  If the
1020       client detects a change in a directory's mtime, the  client  drops  all
1021       cached  LOOKUP results for that directory.  Since the directory's mtime
1022       is a cached attribute, it may take some time before a client notices it
1023       has  changed.  See the descriptions of the acdirmin, acdirmax, and noac
1024       mount options for more information about how long a  directory's  mtime
1025       is cached.
1027       Caching directory entries improves the performance of applications that
1028       do not share files with applications on other  clients.   Using  cached
1029       information  about directories can interfere with applications that run
1030       concurrently on multiple clients and need to detect the creation or re‐
1031       moval  of  files quickly, however.  The lookupcache mount option allows
1032       some tuning of directory entry caching behavior.
1034       Before kernel release 2.6.28, the Linux NFS client tracked  only  posi‐
1035       tive  lookup results.  This permitted applications to detect new direc‐
1036       tory entries created by other clients  quickly  while  still  providing
1037       some of the performance benefits of caching.  If an application depends
1038       on the previous lookup caching behavior of the Linux  NFS  client,  you
1039       can use lookupcache=positive.
1041       If  the client ignores its cache and validates every application lookup
1042       request with the server, that client can immediately detect when a  new
1043       directory  entry  has been either created or removed by another client.
1044       You can specify this behavior using lookupcache=none.   The  extra  NFS
1045       requests  needed if the client does not cache directory entries can ex‐
1046       act a performance penalty.  Disabling lookup caching should  result  in
1047       less of a performance penalty than using noac, and has no effect on how
1048       the NFS client caches the attributes of files.
1050   The sync mount option
1051       The NFS client treats the sync mount option differently than some other
1052       file  systems  (refer to mount(8) for a description of the generic sync
1053       and async mount options).  If neither sync nor async is  specified  (or
1054       if the async option is specified), the NFS client delays sending appli‐
1055       cation writes to the server until any of these events occur:
1057              Memory pressure forces reclamation of system memory resources.
1059              An  application  flushes  file  data  explicitly  with  sync(2),
1060              msync(2), or fsync(3).
1062              An application closes a file with close(2).
1064              The file is locked/unlocked via fcntl(2).
1066       In other words, under normal circumstances, data written by an applica‐
1067       tion may not immediately appear on the server that hosts the file.
1069       If the sync option is specified on a mount point, any system call  that
1070       writes data to files on that mount point causes that data to be flushed
1071       to the server before the system call returns  control  to  user  space.
1072       This provides greater data cache coherence among clients, but at a sig‐
1073       nificant performance cost.
1075       Applications can use the O_SYNC open flag to force  application  writes
1076       to  individual files to go to the server immediately without the use of
1077       the sync mount option.
1079   Using file locks with NFS
1080       The Network Lock Manager protocol is a separate sideband protocol  used
1081       to  manage file locks in NFS version 3.  To support lock recovery after
1082       a client or server reboot, a second sideband protocol -- known  as  the
1083       Network Status Manager protocol -- is also required.  In NFS version 4,
1084       file locking is supported directly in the main NFS  protocol,  and  the
1085       NLM and NSM sideband protocols are not used.
1087       In  most  cases, NLM and NSM services are started automatically, and no
1088       extra configuration is required.  Configure all NFS clients with fully-
1089       qualified  domain  names to ensure that NFS servers can find clients to
1090       notify them of server reboots.
1092       NLM supports advisory file locks only.  To lock NFS files, use fcntl(2)
1093       with  the  F_GETLK  and F_SETLK commands.  The NFS client converts file
1094       locks obtained via flock(2) to advisory locks.
1096       When mounting servers that do not support the  NLM  protocol,  or  when
1097       mounting  an  NFS server through a firewall that blocks the NLM service
1098       port, specify the nolock mount option. NLM  locking  must  be  disabled
1099       with  the  nolock option when using NFS to mount /var because /var con‐
1100       tains files used by the NLM implementation on Linux.
1102       Specifying the nolock option may also be advised to improve the perfor‐
1103       mance  of  a  proprietary application which runs on a single client and
1104       uses file locks extensively.
1106   NFS version 4 caching features
1107       The data and metadata caching behavior of NFS version 4 clients is sim‐
1108       ilar to that of earlier versions.  However, NFS version 4 adds two fea‐
1109       tures that improve cache behavior: change attributes and  file  delega‐
1110       tion.
1112       The  change  attribute is a new part of NFS file and directory metadata
1113       which tracks data changes.  It replaces the use of a  file's  modifica‐
1114       tion  and  change time stamps as a way for clients to validate the con‐
1115       tent of their caches.  Change attributes are independent  of  the  time
1116       stamp resolution on either the server or client, however.
1118       A  file  delegation  is  a contract between an NFS version 4 client and
1119       server that allows the client to treat a  file  temporarily  as  if  no
1120       other client is accessing it.  The server promises to notify the client
1121       (via a callback request) if another  client  attempts  to  access  that
1122       file.  Once a file has been delegated to a client, the client can cache
1123       that file's data  and  metadata  aggressively  without  contacting  the
1124       server.
1126       File  delegations  come in two flavors: read and write.  A read delega‐
1127       tion means that the server notifies the client about any other  clients
1128       that  want  to  write  to  the file.  A write delegation means that the
1129       client gets notified about either read or write accessors.
1131       Servers grant file delegations when a file is opened,  and  can  recall
1132       delegations  at  any  time when another client wants access to the file
1133       that conflicts with any delegations already  granted.   Delegations  on
1134       directories are not supported.
1136       In  order to support delegation callback, the server checks the network
1137       return path to the client during the client's initial contact with  the
1138       server.   If  contact with the client cannot be established, the server
1139       simply does not grant any delegations to that client.


1142       NFS servers control access to file data, but they depend on  their  RPC
1143       implementation  to provide authentication of NFS requests.  Traditional
1144       NFS access control mimics the standard mode bit access control provided
1145       in local file systems.  Traditional RPC authentication uses a number to
1146       represent each user (usually the user's own uid), a number to represent
1147       the  user's  group  (the  user's  gid), and a set of up to 16 auxiliary
1148       group numbers to represent other groups of which the user may be a mem‐
1149       ber.
1151       Typically,  file  data  and user ID values appear unencrypted (i.e. "in
1152       the clear") on the network.  Moreover, NFS versions 2 and 3  use  sepa‐
1153       rate  sideband protocols for mounting, locking and unlocking files, and
1154       reporting system status of clients and servers.  These auxiliary proto‐
1155       cols use no authentication.
1157       In  addition  to  combining  these sideband protocols with the main NFS
1158       protocol, NFS version 4 introduces more advanced forms of  access  con‐
1159       trol,  authentication, and in-transit data protection.  The NFS version
1160       4 specification mandates support for strong authentication and security
1161       flavors  that  provide  per-RPC integrity checking and encryption.  Be‐
1162       cause NFS version 4 combines the function  of  the  sideband  protocols
1163       into  the main NFS protocol, the new security features apply to all NFS
1164       version 4 operations including  mounting,  file  locking,  and  so  on.
1165       RPCGSS  authentication  can also be used with NFS versions 2 and 3, but
1166       it does not protect their sideband protocols.
1168       The sec mount option specifies the security flavor used for  operations
1169       on  behalf  of users on that NFS mount point.  Specifying sec=krb5 pro‐
1170       vides cryptographic proof of a user's identity  in  each  RPC  request.
1171       This  provides  strong  verification of the identity of users accessing
1172       data on the server.  Note that additional configuration besides  adding
1173       this  mount  option  is  required in order to enable Kerberos security.
1174       Refer to the rpc.gssd(8) man page for details.
1176       Two additional flavors of Kerberos security are  supported:  krb5i  and
1177       krb5p.   The  krb5i security flavor provides a cryptographically strong
1178       guarantee that the data in each RPC request has not been tampered with.
1179       The  krb5p  security  flavor encrypts every RPC request to prevent data
1180       exposure during network transit; however, expect some  performance  im‐
1181       pact  when using integrity checking or encryption.  Similar support for
1182       other forms of cryptographic security is also available.
1184   NFS version 4 filesystem crossing
1185       The NFS version 4 protocol allows a client to renegotiate the  security
1186       flavor  when  the  client  crosses into a new filesystem on the server.
1187       The newly negotiated flavor effects only accesses of the  new  filesys‐
1188       tem.
1190       Such negotiation typically occurs when a client crosses from a server's
1191       pseudo-fs into one of the server's exported physical filesystems, which
1192       often have more restrictive security settings than the pseudo-fs.
1194   NFS version 4 Leases
1195       In NFS version 4, a lease is a period during which a server irrevocably
1196       grants a client file locks.  Once the lease expires, the server may re‐
1197       voke  those  locks.  Clients periodically renew their leases to prevent
1198       lock revocation.
1200       After an NFS version 4 server reboots, each  client  tells  the  server
1201       about  existing  file open and lock state under its lease before opera‐
1202       tion can continue.  If a client reboots, the server frees all open  and
1203       lock state associated with that client's lease.
1205       When  establishing a lease, therefore, a client must identify itself to
1206       a server.  Each client presents an arbitrary string to distinguish  it‐
1207       self  from  other clients.  The client administrator can supplement the
1208       default identity string using the nfs4.nfs4_unique_id module  parameter
1209       to avoid collisions with other client identity strings.
1211       A  client  also uses a unique security flavor and principal when it es‐
1212       tablishes its lease.  If two clients present the same identity  string,
1213       a  server  can  use client principals to distinguish between them, thus
1214       securely preventing one client from interfering with the other's lease.
1216       The Linux NFS client establishes  one  lease  on  each  NFS  version  4
1217       server.   Lease  management  operations, such as lease renewal, are not
1218       done on behalf of a particular file, lock, user, or mount point, but on
1219       behalf  of the client that owns that lease.  A client uses a consistent
1220       identity string, security flavor, and principal across  client  reboots
1221       to ensure that the server can promptly reap expired lease state.
1223       When  Kerberos  is  configured  on a Linux NFS client (i.e., there is a
1224       /etc/krb5.keytab on that client), the client attempts to use a Kerberos
1225       security flavor for its lease management operations.  Kerberos provides
1226       secure authentication of each client.  By default, the client uses  the
1227       host/  or  nfs/ service principal in its /etc/krb5.keytab for this pur‐
1228       pose, as described in rpc.gssd(8).
1230       If the client has Kerberos configured, but the server does not,  or  if
1231       the  client does not have a keytab or the requisite service principals,
1232       the client uses AUTH_SYS and UID 0 for lease management.
1234   Using non-privileged source ports
1235       NFS clients usually communicate with NFS servers via  network  sockets.
1236       Each end of a socket is assigned a port value, which is simply a number
1237       between 1 and 65535 that distinguishes socket endpoints at the same  IP
1238       address.   A  socket  is  uniquely defined by a tuple that includes the
1239       transport protocol (TCP or UDP) and the port values and IP addresses of
1240       both endpoints.
1242       The  NFS  client  can choose any source port value for its sockets, but
1243       usually chooses a privileged port.  A privileged port is a  port  value
1244       less  than  1024.   Only  a  process  with root privileges may create a
1245       socket with a privileged source port.
1247       The exact range of privileged source ports that can be chosen is set by
1248       a pair of sysctls to avoid choosing a well-known port, such as the port
1249       used by ssh.  This means the number of source ports available  for  the
1250       NFS  client, and therefore the number of socket connections that can be
1251       used at the same time, is practically limited to only a few hundred.
1253       As described above, the traditional default NFS authentication  scheme,
1254       known as AUTH_SYS, relies on sending local UID and GID numbers to iden‐
1255       tify users making NFS requests.  An NFS server assumes that if  a  con‐
1256       nection  comes  from  a privileged port, the UID and GID numbers in the
1257       NFS requests on this connection have been verified by the client's ker‐
1258       nel  or  some  other local authority.  This is an easy system to spoof,
1259       but on a trusted physical network between trusted hosts, it is entirely
1260       adequate.
1262       Roughly  speaking,  one  socket is used for each NFS mount point.  If a
1263       client could use non-privileged source ports as  well,  the  number  of
1264       sockets  allowed,  and  thus  the  maximum  number  of concurrent mount
1265       points, would be much larger.
1267       Using non-privileged source ports may compromise server security  some‐
1268       what, since any user on AUTH_SYS mount points can now pretend to be any
1269       other when making NFS requests.  Thus NFS servers do not  support  this
1270       by default.  They explicitly allow it usually via an export option.
1272       To  retain  good security while allowing as many mount points as possi‐
1273       ble, it is best to allow non-privileged client connections only if  the
1274       server and client both require strong authentication, such as Kerberos.
1276   Mounting through a firewall
1277       A  firewall  may reside between an NFS client and server, or the client
1278       or server may block some of its own ports via IP filter rules.   It  is
1279       still  possible  to mount an NFS server through a firewall, though some
1280       of the mount(8) command's automatic service endpoint  discovery  mecha‐
1281       nisms  may not work; this requires you to provide specific endpoint de‐
1282       tails via NFS mount options.
1284       NFS servers normally run a portmapper or rpcbind  daemon  to  advertise
1285       their  service  endpoints to clients. Clients use the rpcbind daemon to
1286       determine:
1288              What network port each RPC-based service is using
1290              What transport protocols each RPC-based service supports
1292       The rpcbind daemon uses a well-known port number (111) to help  clients
1293       find  a service endpoint.  Although NFS often uses a standard port num‐
1294       ber (2049), auxiliary services such as the NLM service can  choose  any
1295       unused port number at random.
1297       Common  firewall  configurations block the well-known rpcbind port.  In
1298       the absense of an rpcbind service, the server administrator  fixes  the
1299       port  number of NFS-related services so that the firewall can allow ac‐
1300       cess to specific NFS service ports.  Client administrators then specify
1301       the  port  number  for  the  mountd  service via the mount(8) command's
1302       mountport option.  It may also be necessary to enforce the use  of  TCP
1303       or UDP if the firewall blocks one of those transports.
1305   NFS Access Control Lists
1306       Solaris allows NFS version 3 clients direct access to POSIX Access Con‐
1307       trol Lists stored in its local file systems.  This proprietary sideband
1308       protocol,  known  as  NFSACL,  provides richer access control than mode
1309       bits.  Linux implements this protocol for compatibility  with  the  So‐
1310       laris  NFS implementation.  The NFSACL protocol never became a standard
1311       part of the NFS version 3 specification, however.
1313       The NFS version 4 specification mandates a new version of  Access  Con‐
1314       trol Lists that are semantically richer than POSIX ACLs.  NFS version 4
1315       ACLs are not fully compatible with POSIX ACLs; as such,  some  transla‐
1316       tion  between  the  two  is required in an environment that mixes POSIX
1317       ACLs and NFS version 4.


1320       Generic mount options such as rw and sync can be modified on NFS  mount
1321       points  using the remount option.  See mount(8) for more information on
1322       generic mount options.
1324       With few exceptions, NFS-specific options are not able to  be  modified
1325       during  a  remount.   The underlying transport or NFS version cannot be
1326       changed by a remount, for example.
1328       Performing a remount on an NFS file system mounted with the noac option
1329       may  have unintended consequences.  The noac option is a combination of
1330       the generic option sync, and the NFS-specific option actimeo=0.
1332   Unmounting after a remount
1333       For mount points that use NFS versions 2 or 3, the NFS  umount  subcom‐
1334       mand  depends on knowing the original set of mount options used to per‐
1335       form the MNT operation.  These options are stored on disk  by  the  NFS
1336       mount subcommand, and can be erased by a remount.
1338       To ensure that the saved mount options are not erased during a remount,
1339       specify either the local mount directory, or the  server  hostname  and
1340       export pathname, but not both, during a remount.  For example,
1342               mount -o remount,ro /mnt
1344       merges the mount option ro with the mount options already saved on disk
1345       for the NFS server mounted at /mnt.


1348       /etc/fstab     file system table
1350       /etc/nfsmount.conf
1351                      Configuration file for NFS mounts


1354       Before 2.4.7, the Linux NFS client did not support NFS over TCP.
1356       Before 2.4.20, the Linux NFS  client  used  a  heuristic  to  determine
1357       whether cached file data was still valid rather than using the standard
1358       close-to-open cache coherency method described above.
1360       Starting with 2.4.22, the Linux NFS client employs a Van Jacobsen-based
1361       RTT  estimator  to  determine  retransmit timeout values when using NFS
1362       over UDP.
1364       Before 2.6.0, the Linux NFS client did not support NFS version 4.
1366       Before 2.6.8, the Linux NFS client  used  only  synchronous  reads  and
1367       writes when the rsize and wsize settings were smaller than the system's
1368       page size.
1370       The Linux client's support for protocol versions depend on whether  the
1371       kernel  was  built  with  options  CONFIG_NFS_V2,  CONFIG_NFS_V3,  CON‐
1372       FIG_NFS_V4, CONFIG_NFS_V4_1, and CONFIG_NFS_V4_2.


1375       fstab(5), mount(8), umount(8), mount.nfs(5), umount.nfs(5), exports(5),
1376       nfsmount.conf(5),   netconfig(5),   ipv6(7),   nfsd(8),   sm-notify(8),
1377       rpc.statd(8), rpc.idmapd(8), rpc.gssd(8), rpc.svcgssd(8), kerberos(1)
1379       RFC 768 for the UDP specification.
1380       RFC 793 for the TCP specification.
1381       RFC 1813 for the NFS version 3 specification.
1382       RFC 1832 for the XDR specification.
1383       RFC 1833 for the RPC bind specification.
1384       RFC 2203 for the RPCSEC GSS API protocol specification.
1385       RFC 7530 for the NFS version 4.0 specification.
1386       RFC 5661 for the NFS version 4.1 specification.
1387       RFC 7862 for the NFS version 4.2 specification.
1391                                9 October 2012                          NFS(5)