1NFS(5) File Formats Manual NFS(5)
2
6 nfs - fstab format and options for the nfs file systems
7
9 /etc/fstab
10
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. The Linux NFS client supports three versions
15 of the NFS protocol: NFS version 2 [RFC1094], NFS version 3 [RFC1813],
16 and NFS version 4 [RFC3530].
17 The mount(8) command attaches a file system to the system's name space
19 hierarchy at a given mount point. The /etc/fstab file describes how
20 mount(8) should assemble a system's file name hierarchy from various
21 independent file systems (including file systems exported by NFS
22 servers). Each line in the /etc/fstab file describes a single file
23 system, its mount point, and a set of default mount options for that
24 mount point.
25 For NFS file system mounts, a line in the /etc/fstab file specifies the
27 server name, the path name of the exported server directory to mount,
28 the local directory that is the mount point, the type of file system
29 that is being mounted, and a list of mount options that control the way
30 the filesystem is mounted and how the NFS client behaves when accessing
31 files on this mount point. The fifth and sixth fields on each line are
32 not used by NFS, thus conventionally each contain the digit zero. For
33 example:
34 server:path /mountpoint fstype option,option,... 0 0
36 The server's hostname and export pathname are separated by a colon,
38 while the mount options are separated by commas. The remaining fields
39 are separated by blanks or tabs.
40 The server's hostname can be an unqualified hostname, a fully qualified
42 domain name, a dotted quad IPv4 address, or an IPv6 address enclosed in
43 square brackets. Link-local and site-local IPv6 addresses must be
44 accompanied by an interface identifier. See ipv6(7) for details on
45 specifying raw IPv6 addresses.
46 The fstype field contains "nfs". Use of the "nfs4" fstype in
48 /etc/fstab is deprecated.
49
51 Refer to mount(8) for a description of generic mount options available
52 for all file systems. If you do not need to specify any mount options,
53 use the generic option defaults in /etc/fstab.
54 Options supported by all versions
56 These options are valid to use with any NFS version.
57 soft / hard Determines the recovery behavior of the NFS client after
59 an NFS request times out. If neither option is speci‐
60 fied (or if the hard option is specified), NFS requests
61 are retried indefinitely. If the soft option is speci‐
62 fied, then the NFS client fails an NFS request after
63 retrans retransmissions have been sent, causing the NFS
64 client to return an error to the calling application.
65 NB: A so-called "soft" timeout can cause silent data
67 corruption in certain cases. As such, use the soft
68 option only when client responsiveness is more important
69 than data integrity. Using NFS over TCP or increasing
70 the value of the retrans option may mitigate some of the
71 risks of using the soft option.
72 timeo=n The time in deciseconds (tenths of a second) the NFS
74 client waits for a response before it retries an NFS
75 request.
76 For NFS over TCP the default timeo value is 600 (60 sec‐
78 onds). The NFS client performs linear backoff: After
79 each retransmission the timeout is increased by timeo up
80 to the maximum of 600 seconds.
81 However, for NFS over UDP, the client uses an adaptive
83 algorithm to estimate an appropriate timeout value for
84 frequently used request types (such as READ and WRITE
85 requests), but uses the timeo setting for infrequently
86 used request types (such as FSINFO requests). If the
87 timeo option is not specified, infrequently used request
88 types are retried after 1.1 seconds. After each
89 retransmission, the NFS client doubles the timeout for
90 that request, up to a maximum timeout length of 60 sec‐
91 onds.
92 retrans=n The number of times the NFS client retries a request
94 before it attempts further recovery action. If the
95 retrans option is not specified, the NFS client tries
96 each request three times with mounts using UDP and two
97 times mounts using TCP.
98 The NFS client generates a "server not responding" mes‐
100 sage after retrans retries, then attempts further recov‐
101 ery (depending on whether the hard mount option is in
102 effect).
103 rsize=n The maximum number of bytes in each network READ request
105 that the NFS client can receive when reading data from a
106 file on an NFS server. The actual data payload size of
107 each NFS READ request is equal to or smaller than the
108 rsize setting. The largest read payload supported by the
109 Linux NFS client is 1,048,576 bytes (one megabyte).
110 The rsize value is a positive integral multiple of 1024.
112 Specified rsize values lower than 1024 are replaced with
113 4096; values larger than 1048576 are replaced with
114 1048576. If a specified value is within the supported
115 range but not a multiple of 1024, it is rounded down to
116 the nearest multiple of 1024.
117 If an rsize value is not specified, or if the specified
119 rsize value is larger than the maximum that either
120 client or server can support, the client and server
121 negotiate the largest rsize value that they can both
122 support.
123 The rsize mount option as specified on the mount(8) com‐
125 mand line appears in the /etc/mtab file. However, the
126 effective rsize value negotiated by the client and
127 server is reported in the /proc/mounts file.
128 wsize=n The maximum number of bytes per network WRITE request
130 that the NFS client can send when writing data to a file
131 on an NFS server. The actual data payload size of each
132 NFS WRITE request is equal to or smaller than the wsize
133 setting. The largest write payload supported by the
134 Linux NFS client is 1,048,576 bytes (one megabyte).
135 Similar to rsize , the wsize value is a positive inte‐
137 gral multiple of 1024. Specified wsize values lower
138 than 1024 are replaced with 4096; values larger than
139 1048576 are replaced with 1048576. If a specified value
140 is within the supported range but not a multiple of
141 1024, it is rounded down to the nearest multiple of
142 1024.
143 If a wsize value is not specified, or if the specified
145 wsize value is larger than the maximum that either
146 client or server can support, the client and server
147 negotiate the largest wsize value that they can both
148 support.
149 The wsize mount option as specified on the mount(8) com‐
151 mand line appears in the /etc/mtab file. However, the
152 effective wsize value negotiated by the client and
153 server is reported in the /proc/mounts file.
154 ac / noac Selects whether the client may cache file attributes. If
156 neither option is specified (or if ac is specified), the
157 client caches file attributes.
158 To improve performance, NFS clients cache file
160 attributes. Every few seconds, an NFS client checks the
161 server's version of each file's attributes for updates.
162 Changes that occur on the server in those small inter‐
163 vals remain undetected until the client checks the
164 server again. The noac option prevents clients from
165 caching file attributes so that applications can more
166 quickly detect file changes on the server.
167 In addition to preventing the client from caching file
169 attributes, the noac option forces application writes to
170 become synchronous so that local changes to a file
171 become visible on the server immediately. That way,
172 other clients can quickly detect recent writes when they
173 check the file's attributes.
174 Using the noac option provides greater cache coherence
176 among NFS clients accessing the same files, but it
177 extracts a significant performance penalty. As such,
178 judicious use of file locking is encouraged instead.
179 The DATA AND METADATA COHERENCE section contains a
180 detailed discussion of these trade-offs.
181 acregmin=n The minimum time (in seconds) that the NFS client caches
183 attributes of a regular file before it requests fresh
184 attribute information from a server. If this option is
185 not specified, the NFS client uses a 3-second minimum.
186 acregmax=n The maximum time (in seconds) that the NFS client caches
188 attributes of a regular file before it requests fresh
189 attribute information from a server. If this option is
190 not specified, the NFS client uses a 60-second maximum.
191 acdirmin=n The minimum time (in seconds) that the NFS client caches
193 attributes of a directory before it requests fresh
194 attribute information from a server. If this option is
195 not specified, the NFS client uses a 30-second minimum.
196 acdirmax=n The maximum time (in seconds) that the NFS client caches
198 attributes of a directory before it requests fresh
199 attribute information from a server. If this option is
200 not specified, the NFS client uses a 60-second maximum.
201 actimeo=n Using actimeo sets all of acregmin, acregmax, acdirmin,
203 and acdirmax to the same value. If this option is not
204 specified, the NFS client uses the defaults for each of
205 these options listed above.
206 bg / fg Determines how the mount(8) command behaves if an
208 attempt to mount an export fails. The fg option causes
209 mount(8) to exit with an error status if any part of the
210 mount request times out or fails outright. This is
211 called a "foreground" mount, and is the default behavior
212 if neither the fg nor bg mount option is specified.
213 If the bg option is specified, a timeout or failure
215 causes the mount(8) command to fork a child which con‐
216 tinues to attempt to mount the export. The parent imme‐
217 diately returns with a zero exit code. This is known as
218 a "background" mount.
219 If the local mount point directory is missing, the
221 mount(8) command acts as if the mount request timed out.
222 This permits nested NFS mounts specified in /etc/fstab
223 to proceed in any order during system initialization,
224 even if some NFS servers are not yet available. Alter‐
225 natively these issues can be addressed using an auto‐
226 mounter (refer to automount(8) for details).
227 retry=n The number of minutes that the mount(8) command retries
229 an NFS mount operation in the foreground or background
230 before giving up. If this option is not specified, the
231 default value for foreground mounts is 2 minutes, and
232 the default value for background mounts is 10000 minutes
233 (80 minutes shy of one week). If a value of zero is
234 specified, the mount(8) command exits immediately after
235 the first failure.
236 sec=mode The RPCGSS security flavor to use for accessing files on
238 this mount point. If the sec option is not specified,
239 or if sec=sys is specified, the NFS client uses the
240 AUTH_SYS security flavor for all NFS requests on this
241 mount point. Valid security flavors are none, sys,
242 krb5, krb5i, and krb5p, Refer to the SECURITY CONSIDERA‐
243 TIONS section for details.
244 sharecache / nosharecache
246 Determines how the client's data cache and attribute
247 cache are shared when mounting the same export more than
248 once concurrently. Using the same cache reduces memory
249 requirements on the client and presents identical file
250 contents to applications when the same remote file is
251 accessed via different mount points.
252 If neither option is specified, or if the sharecache
254 option is specified, then a single cache is used for all
255 mount points that access the same export. If the
256 nosharecache option is specified, then that mount point
257 gets a unique cache. Note that when data and attribute
258 caches are shared, the mount options from the first
259 mount point take effect for subsequent concurrent mounts
260 of the same export.
261 As of kernel 2.6.18, the behavior specified by noshare‐
263 cache is legacy caching behavior. This is considered a
264 data risk since multiple cached copies of the same file
265 on the same client can become out of sync following a
266 local update of one of the copies.
267 resvport / noresvport
269 Specifies whether the NFS client should use a privileged
270 source port when communicating with an NFS server for
271 this mount point. If this option is not specified, or
272 the resvport option is specified, the NFS client uses a
273 privileged source port. If the noresvport option is
274 specified, the NFS client uses a non-privileged source
275 port. This option is supported in kernels 2.6.28 and
276 later.
277 Using non-privileged source ports helps increase the
279 maximum number of NFS mount points allowed on a client,
280 but NFS servers must be configured to allow clients to
281 connect via non-privileged source ports.
282 Refer to the SECURITY CONSIDERATIONS section for impor‐
284 tant details.
285 lookupcache=mode
287 Specifies how the kernel manages its cache of directory
288 entries for a given mount point. mode can be one of
289 all, none, pos, or positive. This option is supported
290 in kernels 2.6.28 and later.
291 The Linux NFS client caches the result of all NFS LOOKUP
293 requests. If the requested directory entry exists on
294 the server, the result is referred to as positive. If
295 the requested directory entry does not exist on the
296 server, the result is referred to as negative.
297 If this option is not specified, or if all is specified,
299 the client assumes both types of directory cache entries
300 are valid until their parent directory's cached
301 attributes expire.
302 If pos or positive is specified, the client assumes pos‐
304 itive entries are valid until their parent directory's
305 cached attributes expire, but always revalidates nega‐
306 tive entires before an application can use them.
307 If none is specified, the client revalidates both types
309 of directory cache entries before an application can use
310 them. This permits quick detection of files that were
311 created or removed by other clients, but can impact
312 application and server performance.
313 The DATA AND METADATA COHERENCE section contains a
315 detailed discussion of these trade-offs.
316 Options for NFS versions 2 and 3 only
318 Use these options, along with the options in the above subsection, for
319 NFS versions 2 and 3 only.
320 proto=netid The transport protocol name and protocol family the NFS
322 client uses to transmit requests to the NFS server for
323 this mount point. If an NFS server has both an IPv4 and
324 an IPv6 address, using a specific netid will force the
325 use of IPv4 or IPv6 networking to communicate with that
326 server.
327 If support for TI-RPC is built into the mount.nfs com‐
329 mand, netid is a valid netid listed in /etc/netconfig.
330 The value "rdma" may also be specified. If the
331 mount.nfs command does not have TI-RPC support, then
332 netid is one of "tcp," "udp," or "rdma," and only IPv4
333 may be used.
334 Each transport protocol uses different default retrans
336 and timeo settings. Refer to the description of these
337 two mount options for details.
338 In addition to controlling how the NFS client transmits
340 requests to the server, this mount option also controls
341 how the mount(8) command communicates with the server's
342 rpcbind and mountd services. Specifying a netid that
343 uses TCP forces all traffic from the mount(8) command
344 and the NFS client to use TCP. Specifying a netid that
345 uses UDP forces all traffic types to use UDP.
346 If the proto mount option is not specified, the mount(8)
348 command discovers which protocols the server supports
349 and chooses an appropriate transport for each service.
350 Refer to the TRANSPORT METHODS section for more details.
351 udp The udp option is an alternative to specifying
353 proto=udp. It is included for compatibility with other
354 operating systems.
355 tcp The tcp option is an alternative to specifying
357 proto=tcp. It is included for compatibility with other
358 operating systems.
359 rdma The rdma option is an alternative to specifying
361 proto=rdma.
362 port=n The numeric value of the server's NFS service port. If
364 the server's NFS service is not available on the speci‐
365 fied port, the mount request fails.
366 If this option is not specified, or if the specified
368 port value is 0, then the NFS client uses the NFS ser‐
369 vice port number advertised by the server's rpcbind ser‐
370 vice. The mount request fails if the server's rpcbind
371 service is not available, the server's NFS service is
372 not registered with its rpcbind service, or the server's
373 NFS service is not available on the advertised port.
374 mountport=n The numeric value of the server's mountd port. If the
376 server's mountd service is not available on the speci‐
377 fied port, the mount request fails.
378 If this option is not specified, or if the specified
380 port value is 0, then the mount(8) command uses the
381 mountd service port number advertised by the server's
382 rpcbind service. The mount request fails if the
383 server's rpcbind service is not available, the server's
384 mountd service is not registered with its rpcbind ser‐
385 vice, or the server's mountd service is not available on
386 the advertised port.
387 This option can be used when mounting an NFS server
389 through a firewall that blocks the rpcbind protocol.
390 mountproto=netid
392 The transport protocol name and protocol family the NFS
393 client uses to transmit requests to the NFS server's
394 mountd service when performing this mount request, and
395 when later unmounting this mount point.
396 If support for TI-RPC is built into the mount.nfs com‐
398 mand, netid is a valid netid listed in /etc/netconfig.
399 Otherwise, netid is one of "tcp" or "udp," and only IPv4
400 may be used.
401 This option can be used when mounting an NFS server
403 through a firewall that blocks a particular transport.
404 When used in combination with the proto option, differ‐
405 ent transports for mountd requests and NFS requests can
406 be specified. If the server's mountd service is not
407 available via the specified transport, the mount request
408 fails.
409 Refer to the TRANSPORT METHODS section for more on how
411 the mountproto mount option interacts with the proto
412 mount option.
413 mounthost=name The hostname of the host running mountd. If this option
415 is not specified, the mount(8) command assumes that the
416 mountd service runs on the same host as the NFS service.
417 mountvers=n The RPC version number used to contact the server's
419 mountd. If this option is not specified, the client
420 uses a version number appropriate to the requested NFS
421 version. This option is useful when multiple NFS ser‐
422 vices are running on the same remote server host.
423 namlen=n The maximum length of a pathname component on this
425 mount. If this option is not specified, the maximum
426 length is negotiated with the server. In most cases,
427 this maximum length is 255 characters.
428 Some early versions of NFS did not support this negotia‐
430 tion. Using this option ensures that pathconf(3)
431 reports the proper maximum component length to applica‐
432 tions in such cases.
433 nfsvers=n The NFS protocol version number used to contact the
435 server's NFS service. If the server does not support
436 the requested version, the mount request fails. If this
437 option is not specified, the client negotiates a suit‐
438 able version with the server, trying version 4 first,
439 version 3 second, and version 2 last.
440 vers=n This option is an alternative to the nfsvers option. It
442 is included for compatibility with other operating sys‐
443 tems.
444 lock / nolock Selects whether to use the NLM sideband protocol to lock
446 files on the server. If neither option is specified (or
447 if lock is specified), NLM locking is used for this
448 mount point. When using the nolock option, applications
449 can lock files, but such locks provide exclusion only
450 against other applications running on the same client.
451 Remote applications are not affected by these locks.
452 NLM locking must be disabled with the nolock option when
454 using NFS to mount /var because /var contains files used
455 by the NLM implementation on Linux. Using the nolock
456 option is also required when mounting exports on NFS
457 servers that do not support the NLM protocol.
458 intr / nointr Selects whether to allow signals to interrupt file oper‐
460 ations on this mount point. If neither option is speci‐
461 fied (or if nointr is specified), signals do not inter‐
462 rupt NFS file operations. If intr is specified, system
463 calls return EINTR if an in-progress NFS operation is
464 interrupted by a signal.
465 Using the intr option is preferred to using the soft
467 option because it is significantly less likely to result
468 in data corruption.
469 The intr / nointr mount option is deprecated after ker‐
471 nel 2.6.25. Only SIGKILL can interrupt a pending NFS
472 operation on these kernels, and if specified, this mount
473 option is ignored to provide backwards compatibility
474 with older kernels.
475 cto / nocto Selects whether to use close-to-open cache coherence
477 semantics. If neither option is specified (or if cto is
478 specified), the client uses close-to-open cache coher‐
479 ence semantics. If the nocto option is specified, the
480 client uses a non-standard heuristic to determine when
481 files on the server have changed.
482 Using the nocto option may improve performance for read-
484 only mounts, but should be used only if the data on the
485 server changes only occasionally. The DATA AND METADATA
486 COHERENCE section discusses the behavior of this option
487 in more detail.
488 acl / noacl Selects whether to use the NFSACL sideband protocol on
490 this mount point. The NFSACL sideband protocol is a
491 proprietary protocol implemented in Solaris that manages
492 Access Control Lists. NFSACL was never made a standard
493 part of the NFS protocol specification.
494 If neither acl nor noacl option is specified, the NFS
496 client negotiates with the server to see if the NFSACL
497 protocol is supported, and uses it if the server sup‐
498 ports it. Disabling the NFSACL sideband protocol may be
499 necessary if the negotiation causes problems on the
500 client or server. Refer to the SECURITY CONSIDERATIONS
501 section for more details.
502 rdirplus / nordirplus
504 Selects whether to use NFS version 3 READDIRPLUS
505 requests. If this option is not specified, the NFS
506 client uses READDIRPLUS requests on NFS version 3 mounts
507 to read small directories. Some applications perform
508 better if the client uses only READDIR requests for all
509 directories.
510 local_lock=mechanism
512 Specifies whether to use local locking for any or both
513 of the flock and the POSIX locking mechanisms. mecha‐
514 nism can be one of all, flock, posix, or none.
515 The Linux NFS client provides a way to make locks local.
517 This means, the applications can lock files, but such
518 locks provide exclusion only against other applications
519 running on the same client. Remote applications are not
520 affected by these locks.
521 If this option is not specified, or if none is speci‐
523 fied, the client assumes that the locks are not local.
524 If all is specified, the client assumes that both flock
526 and POSIX locks are local.
527 If flock is specified, the client assumes that only
529 flock locks are local and uses NLM sideband protocol to
530 lock files when POSIX locks are used.
531 If posix is specified, the client assumes that POSIX
533 locks are local and uses NLM sideband protocol to lock
534 files when flock locks are used.
535 To support legacy flock behavior similar to that of NFS
537 clients < 2.6.12, use Samba as Samba maps Windows share
538 mode locks as flock. Since NFS clients > 2.6.12 imple‐
539 ment flock by emulating POSIX locks, this will result in
540 conflicting locks.
541 NOTE: When used together, the 'local_lock' mount option
543 will be overridden by 'nolock'/'lock' mount option.
544 Options for NFS version 4 only
546 Use these options, along with the options in the first subsection
547 above, for NFS version 4 and newer.
548 minorversion=n Specifies the protocol minor version number. NFSv4
550 introduces "minor versioning," where NFS protocol
551 enhancements can be introduced without bumping the NFS
552 protocol version number.
553 The minor version can also be be specified using the
555 vers= option. For example, specifying vers=4.1 is the
556 same as specifying vers=4,minorversion=1.
557 proto=netid The transport protocol name and protocol family the NFS
559 client uses to transmit requests to the NFS server for
560 this mount point. If an NFS server has both an IPv4 and
561 an IPv6 address, using a specific netid will force the
562 use of IPv4 or IPv6 networking to communicate with that
563 server.
564 If support for TI-RPC is built into the mount.nfs com‐
566 mand, netid is a valid netid listed in /etc/netconfig.
567 Otherwise, netid is one of "tcp" or "udp," and only IPv4
568 may be used.
569 All NFS version 4 servers are required to support TCP,
571 so if this mount option is not specified, the NFS ver‐
572 sion 4 client uses the TCP protocol. Refer to the
573 TRANSPORT METHODS section for more details.
574 port=n The numeric value of the server's NFS service port. If
576 the server's NFS service is not available on the speci‐
577 fied port, the mount request fails.
578 If this mount option is not specified, the NFS client
580 uses the standard NFS port number of 2049 without first
581 checking the server's rpcbind service. This allows an
582 NFS version 4 client to contact an NFS version 4 server
583 through a firewall that may block rpcbind requests.
584 If the specified port value is 0, then the NFS client
586 uses the NFS service port number advertised by the
587 server's rpcbind service. The mount request fails if
588 the server's rpcbind service is not available, the
589 server's NFS service is not registered with its rpcbind
590 service, or the server's NFS service is not available on
591 the advertised port.
592 intr / nointr Selects whether to allow signals to interrupt file oper‐
594 ations on this mount point. If neither option is speci‐
595 fied (or if intr is specified), system calls return
596 EINTR if an in-progress NFS operation is interrupted by
597 a signal. If nointr is specified, signals do not inter‐
598 rupt NFS operations.
599 Using the intr option is preferred to using the soft
601 option because it is significantly less likely to result
602 in data corruption.
603 The intr / nointr mount option is deprecated after ker‐
605 nel 2.6.25. Only SIGKILL can interrupt a pending NFS
606 operation on these kernels, and if specified, this mount
607 option is ignored to provide backwards compatibility
608 with older kernels.
609 cto / nocto Selects whether to use close-to-open cache coherence
611 semantics for NFS directories on this mount point. If
612 neither cto nor nocto is specified, the default is to
613 use close-to-open cache coherence semantics for directo‐
614 ries.
615 File data caching behavior is not affected by this
617 option. The DATA AND METADATA COHERENCE section dis‐
618 cusses the behavior of this option in more detail.
619 clientaddr=n.n.n.n
621 Specifies a single IPv4 address (in dotted-quad form),
622 or a non-link-local IPv6 address, that the NFS client
623 advertises to allow servers to perform NFS version 4
624 callback requests against files on this mount point. If
625 the server is unable to establish callback connections
626 to clients, performance may degrade, or accesses to
627 files may temporarily hang.
628 If this option is not specified, the mount(8) command
630 attempts to discover an appropriate callback address
631 automatically. The automatic discovery process is not
632 perfect, however. In the presence of multiple client
633 network interfaces, special routing policies, or atypi‐
634 cal network topologies, the exact address to use for
635 callbacks may be nontrivial to determine.
636
638 The nfs4 file system type is an old syntax for specifying NFSv4 usage.
639 It can still be used with all NFSv4-specific and common options,
640 excepted the nfsvers mount option.
641
643 If the mount command is configured to do so, all of the mount options
644 described in the previous section can also be configured in the
645 /etc/nfsmount.conf file. See nfsmount.conf(5) for details.
646
648 To mount an export using NFS version 2, use the nfs file system type
649 and specify the nfsvers=2 mount option. To mount using NFS version 3,
650 use the nfs file system type and specify the nfsvers=3 mount option.
651 To mount using NFS version 4, use either the nfs file system type, with
652 the nfsvers=4 mount option, or the nfs4 file system type.
653 The following example from an /etc/fstab file causes the mount command
655 to negotiate reasonable defaults for NFS behavior.
656 server:/export /mnt nfs defaults 0 0
658 Here is an example from an /etc/fstab file for an NFS version 2 mount
660 over UDP.
661 server:/export /mnt nfs nfsvers=2,proto=udp 0 0
663 Try this example to mount using NFS version 4 over TCP with Kerberos 5
665 mutual authentication.
666 server:/export /mnt nfs4 sec=krb5 0 0
668 This example can be used to mount /usr over NFS.
670 server:/export /usr nfs ro,nolock,nocto,actimeo=3600 0 0
672 This example shows how to mount an NFS server using a raw IPv6 link-
674 local address.
675 [fe80::215:c5ff:fb3e:e2b1%eth0]:/export /mnt nfs defaults 0 0
677
679 NFS clients send requests to NFS servers via Remote Procedure Calls, or
680 RPCs. The RPC client discovers remote service endpoints automatically,
681 handles per-request authentication, adjusts request parameters for dif‐
682 ferent byte endianness on client and server, and retransmits requests
683 that may have been lost by the network or server. RPC requests and
684 replies flow over a network transport.
685 In most cases, the mount(8) command, NFS client, and NFS server can
687 automatically negotiate proper transport and data transfer size set‐
688 tings for a mount point. In some cases, however, it pays to specify
689 these settings explicitly using mount options.
690 Traditionally, NFS clients used the UDP transport exclusively for
692 transmitting requests to servers. Though its implementation is simple,
693 NFS over UDP has many limitations that prevent smooth operation and
694 good performance in some common deployment environments. Even an
695 insignificant packet loss rate results in the loss of whole NFS
696 requests; as such, retransmit timeouts are usually in the subsecond
697 range to allow clients to recover quickly from dropped requests, but
698 this can result in extraneous network traffic and server load.
699 However, UDP can be quite effective in specialized settings where the
701 networks MTU is large relative to NFSs data transfer size (such as net‐
702 work environments that enable jumbo Ethernet frames). In such environ‐
703 ments, trimming the rsize and wsize settings so that each NFS read or
704 write request fits in just a few network frames (or even in a single
705 frame) is advised. This reduces the probability that the loss of a
706 single MTU-sized network frame results in the loss of an entire large
707 read or write request.
708 TCP is the default transport protocol used for all modern NFS implemen‐
710 tations. It performs well in almost every conceivable network environ‐
711 ment and provides excellent guarantees against data corruption caused
712 by network unreliability. TCP is often a requirement for mounting a
713 server through a network firewall.
714 Under normal circumstances, networks drop packets much more frequently
716 than NFS servers drop requests. As such, an aggressive retransmit
717 timeout setting for NFS over TCP is unnecessary. Typical timeout set‐
718 tings for NFS over TCP are between one and ten minutes. After the
719 client exhausts its retransmits (the value of the retrans mount
720 option), it assumes a network partition has occurred, and attempts to
721 reconnect to the server on a fresh socket. Since TCP itself makes net‐
722 work data transfer reliable, rsize and wsize can safely be allowed to
723 default to the largest values supported by both client and server,
724 independent of the network's MTU size.
725 Using the mountproto mount option
727 This section applies only to NFS version 2 and version 3 mounts since
728 NFS version 4 does not use a separate protocol for mount requests.
729 The Linux NFS client can use a different transport for contacting an
731 NFS server's rpcbind service, its mountd service, its Network Lock Man‐
732 ager (NLM) service, and its NFS service. The exact transports employed
733 by the Linux NFS client for each mount point depends on the settings of
734 the transport mount options, which include proto, mountproto, udp, and
735 tcp.
736 The client sends Network Status Manager (NSM) notifications via UDP no
738 matter what transport options are specified, but listens for server NSM
739 notifications on both UDP and TCP. The NFS Access Control List
740 (NFSACL) protocol shares the same transport as the main NFS service.
741 If no transport options are specified, the Linux NFS client uses UDP to
743 contact the server's mountd service, and TCP to contact its NLM and NFS
744 services by default.
745 If the server does not support these transports for these services, the
747 mount(8) command attempts to discover what the server supports, and
748 then retries the mount request once using the discovered transports.
749 If the server does not advertise any transport supported by the client
750 or is misconfigured, the mount request fails. If the bg option is in
751 effect, the mount command backgrounds itself and continues to attempt
752 the specified mount request.
753 When the proto option, the udp option, or the tcp option is specified
755 but the mountproto option is not, the specified transport is used to
756 contact both the server's mountd service and for the NLM and NFS ser‐
757 vices.
758 If the mountproto option is specified but none of the proto, udp or tcp
760 options are specified, then the specified transport is used for the
761 initial mountd request, but the mount command attempts to discover what
762 the server supports for the NFS protocol, preferring TCP if both trans‐
763 ports are supported.
764 If both the mountproto and proto (or udp or tcp) options are specified,
766 then the transport specified by the mountproto option is used for the
767 initial mountd request, and the transport specified by the proto option
768 (or the udp or tcp options) is used for NFS, no matter what order these
769 options appear. No automatic service discovery is performed if these
770 options are specified.
771 If any of the proto, udp, tcp, or mountproto options are specified more
773 than once on the same mount command line, then the value of the right‐
774 most instance of each of these options takes effect.
775
777 Some modern cluster file systems provide perfect cache coherence among
778 their clients. Perfect cache coherence among disparate NFS clients is
779 expensive to achieve, especially on wide area networks. As such, NFS
780 settles for weaker cache coherence that satisfies the requirements of
781 most file sharing types. Normally, file sharing is completely sequen‐
782 tial: first client A opens a file, writes something to it, then closes
783 it; then client B opens the same file, and reads the changes.
784 Close-to-open cache consistency
786 When an application opens a file stored on an NFS server, the NFS
787 client checks that it still exists on the server and is permitted to
788 the opener by sending a GETATTR or ACCESS request. When the applica‐
789 tion closes the file, the NFS client writes back any pending changes to
790 the file so that the next opener can view the changes. This also gives
791 the NFS client an opportunity to report any server write errors to the
792 application via the return code from close(2). The behavior of check‐
793 ing at open time and flushing at close time is referred to as close-to-
794 open cache consistency.
795 Weak cache consistency
797 There are still opportunities for a client's data cache to contain
798 stale data. The NFS version 3 protocol introduced "weak cache consis‐
799 tency" (also known as WCC) which provides a way of efficiently checking
800 a file's attributes before and after a single request. This allows a
801 client to help identify changes that could have been made by other
802 clients.
803 When a client is using many concurrent operations that update the same
805 file at the same time (for example, during asynchronous write behind),
806 it is still difficult to tell whether it was that client's updates or
807 some other client's updates that altered the file.
808 Attribute caching
810 Use the noac mount option to achieve attribute cache coherence among
811 multiple clients. Almost every file system operation checks file
812 attribute information. The client keeps this information cached for a
813 period of time to reduce network and server load. When noac is in
814 effect, a client's file attribute cache is disabled, so each operation
815 that needs to check a file's attributes is forced to go back to the
816 server. This permits a client to see changes to a file very quickly,
817 at the cost of many extra network operations.
818 Be careful not to confuse the noac option with "no data caching." The
820 noac mount option prevents the client from caching file metadata, but
821 there are still races that may result in data cache incoherence between
822 client and server.
823 The NFS protocol is not designed to support true cluster file system
825 cache coherence without some type of application serialization. If
826 absolute cache coherence among clients is required, applications should
827 use file locking. Alternatively, applications can also open their files
828 with the O_DIRECT flag to disable data caching entirely.
829 Directory entry caching
831 The Linux NFS client caches the result of all NFS LOOKUP requests. If
832 the requested directory entry exists on the server, the result is
833 referred to as a positive lookup result. If the requested directory
834 entry does not exist on the server (that is, the server returned
835 ENOENT), the result is referred to as negative lookup result.
836 To detect when directory entries have been added or removed on the
838 server, the Linux NFS client watches a directory's mtime. If the
839 client detects a change in a directory's mtime, the client drops all
840 cached LOOKUP results for that directory. Since the directory's mtime
841 is a cached attribute, it may take some time before a client notices it
842 has changed. See the descriptions of the acdirmin, acdirmax, and noac
843 mount options for more information about how long a directory's mtime
844 is cached.
845 Caching directory entries improves the performance of applications that
847 do not share files with applications on other clients. Using cached
848 information about directories can interfere with applications that run
849 concurrently on multiple clients and need to detect the creation or
850 removal of files quickly, however. The lookupcache mount option allows
851 some tuning of directory entry caching behavior.
852 Before kernel release 2.6.28, the Linux NFS client tracked only posi‐
854 tive lookup results. This permitted applications to detect new direc‐
855 tory entries created by other clients quickly while still providing
856 some of the performance benefits of caching. If an application depends
857 on the previous lookup caching behavior of the Linux NFS client, you
858 can use lookupcache=positive.
859 If the client ignores its cache and validates every application lookup
861 request with the server, that client can immediately detect when a new
862 directory entry has been either created or removed by another client.
863 You can specify this behavior using lookupcache=none. The extra NFS
864 requests needed if the client does not cache directory entries can
865 exact a performance penalty. Disabling lookup caching should result in
866 less of a performance penalty than using noac, and has no effect on how
867 the NFS client caches the attributes of files.
868 The sync mount option
870 The NFS client treats the sync mount option differently than some other
871 file systems (refer to mount(8) for a description of the generic sync
872 and async mount options). If neither sync nor async is specified (or
873 if the async option is specified), the NFS client delays sending appli‐
874 cation writes to the server until any of these events occur:
875 Memory pressure forces reclamation of system memory resources.
877 An application flushes file data explicitly with sync(2),
879 msync(2), or fsync(3).
880 An application closes a file with close(2).
882 The file is locked/unlocked via fcntl(2).
884 In other words, under normal circumstances, data written by an applica‐
886 tion may not immediately appear on the server that hosts the file.
887 If the sync option is specified on a mount point, any system call that
889 writes data to files on that mount point causes that data to be flushed
890 to the server before the system call returns control to user space.
891 This provides greater data cache coherence among clients, but at a sig‐
892 nificant performance cost.
893 Applications can use the O_SYNC open flag to force application writes
895 to individual files to go to the server immediately without the use of
896 the sync mount option.
897 Using file locks with NFS
899 The Network Lock Manager protocol is a separate sideband protocol used
900 to manage file locks in NFS version 2 and version 3. To support lock
901 recovery after a client or server reboot, a second sideband protocol --
902 known as the Network Status Manager protocol -- is also required. In
903 NFS version 4, file locking is supported directly in the main NFS pro‐
904 tocol, and the NLM and NSM sideband protocols are not used.
905 In most cases, NLM and NSM services are started automatically, and no
907 extra configuration is required. Configure all NFS clients with fully-
908 qualified domain names to ensure that NFS servers can find clients to
909 notify them of server reboots.
910 NLM supports advisory file locks only. To lock NFS files, use fcntl(2)
912 with the F_GETLK and F_SETLK commands. The NFS client converts file
913 locks obtained via flock(2) to advisory locks.
914 When mounting servers that do not support the NLM protocol, or when
916 mounting an NFS server through a firewall that blocks the NLM service
917 port, specify the nolock mount option. NLM locking must be disabled
918 with the nolock option when using NFS to mount /var because /var con‐
919 tains files used by the NLM implementation on Linux.
920 Specifying the nolock option may also be advised to improve the perfor‐
922 mance of a proprietary application which runs on a single client and
923 uses file locks extensively.
924 NFS version 4 caching features
926 The data and metadata caching behavior of NFS version 4 clients is sim‐
927 ilar to that of earlier versions. However, NFS version 4 adds two fea‐
928 tures that improve cache behavior: change attributes and file delega‐
929 tion.
930 The change attribute is a new part of NFS file and directory metadata
932 which tracks data changes. It replaces the use of a file's modifica‐
933 tion and change time stamps as a way for clients to validate the con‐
934 tent of their caches. Change attributes are independent of the time
935 stamp resolution on either the server or client, however.
936 A file delegation is a contract between an NFS version 4 client and
938 server that allows the client to treat a file temporarily as if no
939 other client is accessing it. The server promises to notify the client
940 (via a callback request) if another client attempts to access that
941 file. Once a file has been delegated to a client, the client can cache
942 that file's data and metadata aggressively without contacting the
943 server.
944 File delegations come in two flavors: read and write. A read delega‐
946 tion means that the server notifies the client about any other clients
947 that want to write to the file. A write delegation means that the
948 client gets notified about either read or write accessors.
949 Servers grant file delegations when a file is opened, and can recall
951 delegations at any time when another client wants access to the file
952 that conflicts with any delegations already granted. Delegations on
953 directories are not supported.
954 In order to support delegation callback, the server checks the network
956 return path to the client during the client's initial contact with the
957 server. If contact with the client cannot be established, the server
958 simply does not grant any delegations to that client.
959
961 NFS servers control access to file data, but they depend on their RPC
962 implementation to provide authentication of NFS requests. Traditional
963 NFS access control mimics the standard mode bit access control provided
964 in local file systems. Traditional RPC authentication uses a number to
965 represent each user (usually the user's own uid), a number to represent
966 the user's group (the user's gid), and a set of up to 16 auxiliary
967 group numbers to represent other groups of which the user may be a mem‐
968 ber.
969 Typically, file data and user ID values appear unencrypted (i.e. "in
971 the clear") on the network. Moreover, NFS versions 2 and 3 use sepa‐
972 rate sideband protocols for mounting, locking and unlocking files, and
973 reporting system status of clients and servers. These auxiliary proto‐
974 cols use no authentication.
975 In addition to combining these sideband protocols with the main NFS
977 protocol, NFS version 4 introduces more advanced forms of access con‐
978 trol, authentication, and in-transit data protection. The NFS version
979 4 specification mandates NFSv4 ACLs, RPCGSS authentication, and RPCGSS
980 security flavors that provide per-RPC integrity checking and encryp‐
981 tion. Because NFS version 4 combines the function of the sideband pro‐
982 tocols into the main NFS protocol, the new security features apply to
983 all NFS version 4 operations including mounting, file locking, and so
984 on. RPCGSS authentication can also be used with NFS versions 2 and 3,
985 but does not protect their sideband protocols.
986 The sec mount option specifies the RPCGSS security mode that is in
988 effect on a given NFS mount point. Specifying sec=krb5 provides cryp‐
989 tographic proof of a user's identity in each RPC request. This pro‐
990 vides strong verification of the identity of users accessing data on
991 the server. Note that additional configuration besides adding this
992 mount option is required in order to enable Kerberos security. Refer
993 to the rpc.gssd(8) man page for details.
994 Two additional flavors of Kerberos security are supported: krb5i and
996 krb5p. The krb5i security flavor provides a cryptographically strong
997 guarantee that the data in each RPC request has not been tampered with.
998 The krb5p security flavor encrypts every RPC request to prevent data
999 exposure during network transit; however, expect some performance
1000 impact when using integrity checking or encryption. Similar support
1001 for other forms of cryptographic security is also available.
1002 The NFS version 4 protocol allows clients and servers to negotiate
1004 among multiple security flavors during mount processing. However,
1005 Linux does not yet implement such negotiation. The Linux client speci‐
1006 fies a single security flavor at mount time which remains in effect for
1007 the lifetime of the mount. If the server does not support this flavor,
1008 the initial mount request is rejected by the server.
1009 Using non-privileged source ports
1011 NFS clients usually communicate with NFS servers via network sockets.
1012 Each end of a socket is assigned a port value, which is simply a number
1013 between 1 and 65535 that distinguishes socket endpoints at the same IP
1014 address. A socket is uniquely defined by a tuple that includes the
1015 transport protocol (TCP or UDP) and the port values and IP addresses of
1016 both endpoints.
1017 The NFS client can choose any source port value for its sockets, but
1019 usually chooses a privileged port. A privileged port is a port value
1020 less than 1024. Only a process with root privileges may create a
1021 socket with a privileged source port.
1022 The exact range of privileged source ports that can be chosen is set by
1024 a pair of sysctls to avoid choosing a well-known port, such as the port
1025 used by ssh. This means the number of source ports available for the
1026 NFS client, and therefore the number of socket connections that can be
1027 used at the same time, is practically limited to only a few hundred.
1028 As described above, the traditional default NFS authentication scheme,
1030 known as AUTH_SYS, relies on sending local UID and GID numbers to iden‐
1031 tify users making NFS requests. An NFS server assumes that if a con‐
1032 nection comes from a privileged port, the UID and GID numbers in the
1033 NFS requests on this connection have been verified by the client's ker‐
1034 nel or some other local authority. This is an easy system to spoof,
1035 but on a trusted physical network between trusted hosts, it is entirely
1036 adequate.
1037 Roughly speaking, one socket is used for each NFS mount point. If a
1039 client could use non-privileged source ports as well, the number of
1040 sockets allowed, and thus the maximum number of concurrent mount
1041 points, would be much larger.
1042 Using non-privileged source ports may compromise server security some‐
1044 what, since any user on AUTH_SYS mount points can now pretend to be any
1045 other when making NFS requests. Thus NFS servers do not support this
1046 by default. They explicitly allow it usually via an export option.
1047 To retain good security while allowing as many mount points as possi‐
1049 ble, it is best to allow non-privileged client connections only if the
1050 server and client both require strong authentication, such as Kerberos.
1051 Mounting through a firewall
1053 A firewall may reside between an NFS client and server, or the client
1054 or server may block some of its own ports via IP filter rules. It is
1055 still possible to mount an NFS server through a firewall, though some
1056 of the mount(8) command's automatic service endpoint discovery mecha‐
1057 nisms may not work; this requires you to provide specific endpoint
1058 details via NFS mount options.
1059 NFS servers normally run a portmapper or rpcbind daemon to advertise
1061 their service endpoints to clients. Clients use the rpcbind daemon to
1062 determine:
1063 What network port each RPC-based service is using
1065 What transport protocols each RPC-based service supports
1067 The rpcbind daemon uses a well-known port number (111) to help clients
1069 find a service endpoint. Although NFS often uses a standard port num‐
1070 ber (2049), auxiliary services such as the NLM service can choose any
1071 unused port number at random.
1072 Common firewall configurations block the well-known rpcbind port. In
1074 the absense of an rpcbind service, the server administrator fixes the
1075 port number of NFS-related services so that the firewall can allow
1076 access to specific NFS service ports. Client administrators then spec‐
1077 ify the port number for the mountd service via the mount(8) command's
1078 mountport option. It may also be necessary to enforce the use of TCP
1079 or UDP if the firewall blocks one of those transports.
1080 NFS Access Control Lists
1082 Solaris allows NFS version 3 clients direct access to POSIX Access Con‐
1083 trol Lists stored in its local file systems. This proprietary sideband
1084 protocol, known as NFSACL, provides richer access control than mode
1085 bits. Linux implements this protocol for compatibility with the
1086 Solaris NFS implementation. The NFSACL protocol never became a stan‐
1087 dard part of the NFS version 3 specification, however.
1088 The NFS version 4 specification mandates a new version of Access Con‐
1090 trol Lists that are semantically richer than POSIX ACLs. NFS version 4
1091 ACLs are not fully compatible with POSIX ACLs; as such, some transla‐
1092 tion between the two is required in an environment that mixes POSIX
1093 ACLs and NFS version 4.
1094
1096 Generic mount options such as rw and sync can be modified on NFS mount
1097 points using the remount option. See mount(8) for more information on
1098 generic mount options.
1099 With few exceptions, NFS-specific options are not able to be modified
1101 during a remount. The underlying transport or NFS version cannot be
1102 changed by a remount, for example.
1103 Performing a remount on an NFS file system mounted with the noac option
1105 may have unintended consequences. The noac option is a combination of
1106 the generic option sync, and the NFS-specific option actimeo=0.
1107 Unmounting after a remount
1109 For mount points that use NFS versions 2 or 3, the NFS umount subcom‐
1110 mand depends on knowing the original set of mount options used to per‐
1111 form the MNT operation. These options are stored on disk by the NFS
1112 mount subcommand, and can be erased by a remount.
1113 To ensure that the saved mount options are not erased during a remount,
1115 specify either the local mount directory, or the server hostname and
1116 export pathname, but not both, during a remount. For example,
1117 mount -o remount,ro /mnt
1119 merges the mount option ro with the mount options already saved on disk
1121 for the NFS server mounted at /mnt.
1122
1124 /etc/fstab file system table
1125 /etc/nfsmount.conf
1127 Configuration file for NFS mounts
1128
1130 Before 2.4.7, the Linux NFS client did not support NFS over TCP.
1131 Before 2.4.20, the Linux NFS client used a heuristic to determine
1133 whether cached file data was still valid rather than using the standard
1134 close-to-open cache coherency method described above.
1135 Starting with 2.4.22, the Linux NFS client employs a Van Jacobsen-based
1137 RTT estimator to determine retransmit timeout values when using NFS
1138 over UDP.
1139 Before 2.6.0, the Linux NFS client did not support NFS version 4.
1141 Before 2.6.8, the Linux NFS client used only synchronous reads and
1143 writes when the rsize and wsize settings were smaller than the system's
1144 page size.
1145 The Linux NFS client does not yet support certain optional features of
1147 the NFS version 4 protocol, such as security negotiation, server refer‐
1148 rals, and named attributes.
1149
1151 fstab(5), mount(8), umount(8), mount.nfs(5), umount.nfs(5), exports(5),
1152 nfsmount.conf(5), netconfig(5), ipv6(7), nfsd(8), sm-notify(8),
1153 rpc.statd(8), rpc.idmapd(8), rpc.gssd(8), rpc.svcgssd(8), kerberos(1)
1154 RFC 768 for the UDP specification.
1156 RFC 793 for the TCP specification.
1157 RFC 1094 for the NFS version 2 specification.
1158 RFC 1813 for the NFS version 3 specification.
1159 RFC 1832 for the XDR specification.
1160 RFC 1833 for the RPC bind specification.
1161 RFC 2203 for the RPCSEC GSS API protocol specification.
1162 RFC 3530 for the NFS version 4 specification.
1163 2 November 2007 NFS(5)