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