1NFS(5)                        File Formats Manual                       NFS(5)
2
3
4

NAME

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

SYNOPSIS

9       /etc/fstab
10

DESCRIPTION

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 2, 3, 4.0, 4.1, or 4.2.
16
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.
24
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:
33
34               server:path   /mountpoint   fstype   option,option,...   0 0
35
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.
39
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.
45
46       The  fstype  field  contains  "nfs".   Use  of  the  "nfs4"  fstype  in
47       /etc/fstab is deprecated.
48

MOUNT OPTIONS

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.
53
54   Options supported by all versions
55       These options are valid to use with any NFS version.
56
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.
63
64       vers=n         This option is an alternative to the nfsvers option.  It
65                      is included for compatibility with other operating  sys‐
66                      tems
67
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.
75
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.
82
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.
90
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.
98
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.
103
104       intr / nointr  This option is provided for backward compatibility.   It
105                      is ignored after kernel 2.6.25.
106
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.
110
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.
115
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.
126
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.
131
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).
136
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).
143
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.
150
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.
156
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.
161
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).
168
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.
176
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.
182
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.
187
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.
191
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.
200
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.
207
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.
214
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.
221
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.
228
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.
235
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.
242
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.
247
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.
254
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.
260
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).
268
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.
279
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.
283
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.
294
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.
302
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.
311
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.
319
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.
328
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.
336
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.
345
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.
351
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.
361
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.
366
367                      Refer to the SECURITY CONSIDERATIONS section for  impor‐
368                      tant details.
369
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.
375
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.
381
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.
386
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.
391
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.
397
398                      The DATA AND METADATA COHERENCE section contains  a  de‐
399                      tailed discussion of these trade-offs.
400
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.
406
407       sloppy         The  sloppy  option  is  an  alternative  to  specifying
408                      mount.nfs -s option.
409
410
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.
414
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.
420
421                      Each  transport  protocol uses different default retrans
422                      and timeo settings.  Refer to the description  of  these
423                      two mount options for details.
424
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.
432
433                      Before  using NFS over UDP, refer to the TRANSPORT METH‐
434                      ODS section.
435
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.
440
441       udp            The   udp   option   is  an  alternative  to  specifying
442                      proto=udp.  It is included for compatibility with  other
443                      operating systems.
444
445                      Before  using NFS over UDP, refer to the TRANSPORT METH‐
446                      ODS section.
447
448       tcp            The  tcp  option  is  an   alternative   to   specifying
449                      proto=tcp.   It is included for compatibility with other
450                      operating systems.
451
452       rdma           The  rdma  option  is  an  alternative   to   specifying
453                      proto=rdma.
454
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.
458
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.
466
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.
470
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.
479
480                      This option can be used  when  mounting  an  NFS  server
481                      through a firewall that blocks the rpcbind protocol.
482
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.
488
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.
492
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.
500
501                      Refer to the TRANSPORT METHODS section for more  on  how
502                      the  mountproto  mount  option  interacts with the proto
503                      mount option.
504
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.
508
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.
514
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.
519
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.
524
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.
532
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.
538
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.
545
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.
551
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.
557
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.
565
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.
571
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.
577
578                      If this option is not specified, or if  none  is  speci‐
579                      fied, the client assumes that the locks are not local.
580
581                      If  all is specified, the client assumes that both flock
582                      and POSIX locks are local.
583
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.
587
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.
591
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.
598
599                      NOTE:  When used together, the 'local_lock' mount option
600                      will be overridden by 'nolock'/'lock' mount option.
601
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.
605
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.
611
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.
616
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.
624
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.
629
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.
633
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.
639
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.
647
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.
653
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.
657
658       clientaddr=n.n.n.n
659
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 (0.0.0.0) or equivalent IPv6 any address  which
669                      will  signal to the NFS server that this NFS client does
670                      not want delegations.
671
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.
679
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.
684
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.
690
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.
699
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.
703

nfs4 FILE SYSTEM TYPE

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

MOUNT CONFIGURATION FILE

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

EXAMPLES

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

TRANSPORT METHODS

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

DATA AND METADATA COHERENCE

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

SECURITY CONSIDERATIONS

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

THE REMOUNT OPTION

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

FILES

1354       /etc/fstab     file system table
1355
1356       /etc/nfsmount.conf
1357                      Configuration file for NFS mounts
1358

NOTES

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

SEE ALSO

1381       fstab(5), mount(8), umount(8), mount.nfs(5), umount.nfs(5), exports(5),
1382       nfsmount.conf(5),   netconfig(5),   ipv6(7),   nfsd(8),   sm-notify(8),
1383       rpc.statd(8), rpc.idmapd(8), rpc.gssd(8), rpc.svcgssd(8), kerberos(1)
1384
1385       RFC 768 for the UDP specification.
1386       RFC 793 for the TCP specification.
1387       RFC 1094 for the NFS version 2 specification.
1388       RFC 1813 for the NFS version 3 specification.
1389       RFC 1832 for the XDR specification.
1390       RFC 1833 for the RPC bind specification.
1391       RFC 2203 for the RPCSEC GSS API protocol specification.
1392       RFC 7530 for the NFS version 4.0 specification.
1393       RFC 5661 for the NFS version 4.1 specification.
1394       RFC 7862 for the NFS version 4.2 specification.
1395
1396
1397
1398                                9 October 2012                          NFS(5)
Impressum