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. Depending on kernel configuration, the Linux
15 NFS client may support NFS versions 2, 3, 4.0, 4.1, or 4.2.
16 The mount(8) command attaches a file system to the system's name space
18 hierarchy at a given mount point. The /etc/fstab file describes how
19 mount(8) should assemble a system's file name hierarchy from various
20 independent file systems (including file systems exported by NFS
21 servers). Each line in the /etc/fstab file describes a single file
22 system, its mount point, and a set of default mount options for that
23 mount point.
24 For NFS file system mounts, a line in the /etc/fstab file specifies the
26 server name, the path name of the exported server directory to mount,
27 the local directory that is the mount point, the type of file system
28 that is being mounted, and a list of mount options that control the way
29 the filesystem is mounted and how the NFS client behaves when accessing
30 files on this mount point. The fifth and sixth fields on each line are
31 not used by NFS, thus conventionally each contain the digit zero. For
32 example:
33 server:path /mountpoint fstype option,option,... 0 0
35 The server's hostname and export pathname are separated by a colon,
37 while the mount options are separated by commas. The remaining fields
38 are separated by blanks or tabs.
39 The server's hostname can be an unqualified hostname, a fully qualified
41 domain name, a dotted quad IPv4 address, or an IPv6 address enclosed in
42 square brackets. Link-local and site-local IPv6 addresses must be ac‐
43 companied by an interface identifier. See ipv6(7) for details on spec‐
44 ifying raw IPv6 addresses.
45 The fstype field contains "nfs". Use of the "nfs4" fstype in
47 /etc/fstab is deprecated.
48
50 Refer to mount(8) for a description of generic mount options available
51 for all file systems. If you do not need to specify any mount options,
52 use the generic option defaults in /etc/fstab.
53 Options supported by all versions
55 These options are valid to use with any NFS version.
56 nfsvers=n The NFS protocol version number used to contact the
58 server's NFS service. If the server does not support
59 the requested version, the mount request fails. If this
60 option is not specified, the client tries version 4.2
61 first, then negotiates down until it finds a version
62 supported by the server.
63 vers=n This option is an alternative to the nfsvers option. It
65 is included for compatibility with other operating sys‐
66 tems
67 soft / hard Determines the recovery behavior of the NFS client after
69 an NFS request times out. If neither option is speci‐
70 fied (or if the hard option is specified), NFS requests
71 are retried indefinitely. If the soft option is speci‐
72 fied, then the NFS client fails an NFS request after re‐
73 trans retransmissions have been sent, causing the NFS
74 client to return an error to the calling application.
75 NB: A so-called "soft" timeout can cause silent data
77 corruption in certain cases. As such, use the soft op‐
78 tion only when client responsiveness is more important
79 than data integrity. Using NFS over TCP or increasing
80 the value of the retrans option may mitigate some of the
81 risks of using the soft option.
82 softreval / nosoftreval
84 In cases where the NFS server is down, it may be useful
85 to allow the NFS client to continue to serve up paths
86 and attributes from cache after retrans attempts to
87 revalidate that cache have timed out. This may, for in‐
88 stance, be helpful when trying to unmount a filesystem
89 tree from a server that is permanently down.
90 It is possible to combine softreval with the soft mount
92 option, in which case operations that cannot be served
93 up from cache will time out and return an error after
94 retrans attempts. The combination with the default hard
95 mount option implies those uncached operations will con‐
96 tinue to retry until a response is received from the
97 server.
98 Note: the default mount option is nosoftreval which dis‐
100 allows fallback to cache when revalidation fails, and
101 instead follows the behavior dictated by the hard or
102 soft mount option.
103 intr / nointr This option is provided for backward compatibility. It
105 is ignored after kernel 2.6.25.
106 timeo=n The time in deciseconds (tenths of a second) the NFS
108 client waits for a response before it retries an NFS re‐
109 quest.
110 For NFS over TCP the default timeo value is 600 (60 sec‐
112 onds). The NFS client performs linear backoff: After
113 each retransmission the timeout is increased by timeo up
114 to the maximum of 600 seconds.
115 However, for NFS over UDP, the client uses an adaptive
117 algorithm to estimate an appropriate timeout value for
118 frequently used request types (such as READ and WRITE
119 requests), but uses the timeo setting for infrequently
120 used request types (such as FSINFO requests). If the
121 timeo option is not specified, infrequently used request
122 types are retried after 1.1 seconds. After each re‐
123 transmission, the NFS client doubles the timeout for
124 that request, up to a maximum timeout length of 60 sec‐
125 onds.
126 retrans=n The number of times the NFS client retries a request be‐
128 fore it attempts further recovery action. If the retrans
129 option is not specified, the NFS client tries each UDP
130 request three times and each TCP request twice.
131 The NFS client generates a "server not responding" mes‐
133 sage after retrans retries, then attempts further recov‐
134 ery (depending on whether the hard mount option is in
135 effect).
136 rsize=n The maximum number of bytes in each network READ request
138 that the NFS client can receive when reading data from a
139 file on an NFS server. The actual data payload size of
140 each NFS READ request is equal to or smaller than the
141 rsize setting. The largest read payload supported by the
142 Linux NFS client is 1,048,576 bytes (one megabyte).
143 The rsize value is a positive integral multiple of 1024.
145 Specified rsize values lower than 1024 are replaced with
146 4096; values larger than 1048576 are replaced with
147 1048576. If a specified value is within the supported
148 range but not a multiple of 1024, it is rounded down to
149 the nearest multiple of 1024.
150 If an rsize value is not specified, or if the specified
152 rsize value is larger than the maximum that either
153 client or server can support, the client and server ne‐
154 gotiate the largest rsize value that they can both sup‐
155 port.
156 The rsize mount option as specified on the mount(8) com‐
158 mand line appears in the /etc/mtab file. However, the
159 effective rsize value negotiated by the client and
160 server is reported in the /proc/mounts file.
161 wsize=n The maximum number of bytes per network WRITE request
163 that the NFS client can send when writing data to a file
164 on an NFS server. The actual data payload size of each
165 NFS WRITE request is equal to or smaller than the wsize
166 setting. The largest write payload supported by the
167 Linux NFS client is 1,048,576 bytes (one megabyte).
168 Similar to rsize , the wsize value is a positive inte‐
170 gral multiple of 1024. Specified wsize values lower
171 than 1024 are replaced with 4096; values larger than
172 1048576 are replaced with 1048576. If a specified value
173 is within the supported range but not a multiple of
174 1024, it is rounded down to the nearest multiple of
175 1024.
176 If a wsize value is not specified, or if the specified
178 wsize value is larger than the maximum that either
179 client or server can support, the client and server ne‐
180 gotiate the largest wsize value that they can both sup‐
181 port.
182 The wsize mount option as specified on the mount(8) com‐
184 mand line appears in the /etc/mtab file. However, the
185 effective wsize value negotiated by the client and
186 server is reported in the /proc/mounts file.
187 ac / noac Selects whether the client may cache file attributes. If
189 neither option is specified (or if ac is specified), the
190 client caches file attributes.
191 To improve performance, NFS clients cache file at‐
193 tributes. Every few seconds, an NFS client checks the
194 server's version of each file's attributes for updates.
195 Changes that occur on the server in those small inter‐
196 vals remain undetected until the client checks the
197 server again. The noac option prevents clients from
198 caching file attributes so that applications can more
199 quickly detect file changes on the server.
200 In addition to preventing the client from caching file
202 attributes, the noac option forces application writes to
203 become synchronous so that local changes to a file be‐
204 come visible on the server immediately. That way, other
205 clients can quickly detect recent writes when they check
206 the file's attributes.
207 Using the noac option provides greater cache coherence
209 among NFS clients accessing the same files, but it ex‐
210 tracts a significant performance penalty. As such, ju‐
211 dicious use of file locking is encouraged instead. The
212 DATA AND METADATA COHERENCE section contains a detailed
213 discussion of these trade-offs.
214 acregmin=n The minimum time (in seconds) that the NFS client caches
216 attributes of a regular file before it requests fresh
217 attribute information from a server. If this option is
218 not specified, the NFS client uses a 3-second minimum.
219 See the DATA AND METADATA COHERENCE section for a full
220 discussion of attribute caching.
221 acregmax=n The maximum time (in seconds) that the NFS client caches
223 attributes of a regular file before it requests fresh
224 attribute information from a server. If this option is
225 not specified, the NFS client uses a 60-second maximum.
226 See the DATA AND METADATA COHERENCE section for a full
227 discussion of attribute caching.
228 acdirmin=n The minimum time (in seconds) that the NFS client caches
230 attributes of a directory before it requests fresh at‐
231 tribute information from a server. If this option is
232 not specified, the NFS client uses a 30-second minimum.
233 See the DATA AND METADATA COHERENCE section for a full
234 discussion of attribute caching.
235 acdirmax=n The maximum time (in seconds) that the NFS client caches
237 attributes of a directory before it requests fresh at‐
238 tribute information from a server. If this option is
239 not specified, the NFS client uses a 60-second maximum.
240 See the DATA AND METADATA COHERENCE section for a full
241 discussion of attribute caching.
242 actimeo=n Using actimeo sets all of acregmin, acregmax, acdirmin,
244 and acdirmax to the same value. If this option is not
245 specified, the NFS client uses the defaults for each of
246 these options listed above.
247 bg / fg Determines how the mount(8) command behaves if an at‐
249 tempt to mount an export fails. The fg option causes
250 mount(8) to exit with an error status if any part of the
251 mount request times out or fails outright. This is
252 called a "foreground" mount, and is the default behavior
253 if neither the fg nor bg mount option is specified.
254 If the bg option is specified, a timeout or failure
256 causes the mount(8) command to fork a child which con‐
257 tinues to attempt to mount the export. The parent imme‐
258 diately returns with a zero exit code. This is known as
259 a "background" mount.
260 If the local mount point directory is missing, the
262 mount(8) command acts as if the mount request timed out.
263 This permits nested NFS mounts specified in /etc/fstab
264 to proceed in any order during system initialization,
265 even if some NFS servers are not yet available. Alter‐
266 natively these issues can be addressed using an auto‐
267 mounter (refer to automount(8) for details).
268 nconnect=n When using a connection oriented protocol such as TCP,
270 it may sometimes be advantageous to set up multiple con‐
271 nections between the client and server. For instance, if
272 your clients and/or servers are equipped with multiple
273 network interface cards (NICs), using multiple connec‐
274 tions to spread the load may improve overall perfor‐
275 mance. In such cases, the nconnect option allows the
276 user to specify the number of connections that should be
277 established between the client and server up to a limit
278 of 16.
279 Note that the nconnect option may also be used by some
281 pNFS drivers to decide how many connections to set up to
282 the data servers.
283 max_connect=n While nconnect option sets a limit on the number of con‐
285 nections that can be established to a given server IP,
286 max_connect option allows the user to specify maximum
287 number of connections to different server IPs that be‐
288 long to the same NFSv4.1+ server (session trunkable con‐
289 nections) up to a limit of 16. When client discovers
290 that it established a client ID to an already existing
291 server, instead of dropping the newly created network
292 transport, the client will add this new connection to
293 the list of available transports for that RPC client.
294 rdirplus / nordirplus
296 Selects whether to use NFS v3 or v4 READDIRPLUS re‐
297 quests. If this option is not specified, the NFS client
298 uses READDIRPLUS requests on NFS v3 or v4 mounts to read
299 small directories. Some applications perform better if
300 the client uses only READDIR requests for all directo‐
301 ries.
302 retry=n The number of minutes that the mount(8) command retries
304 an NFS mount operation in the foreground or background
305 before giving up. If this option is not specified, the
306 default value for foreground mounts is 2 minutes, and
307 the default value for background mounts is 10000 minutes
308 (80 minutes shy of one week). If a value of zero is
309 specified, the mount(8) command exits immediately after
310 the first failure.
311 Note that this only affects how many retries are made
313 and doesn't affect the delay caused by each retry. For
314 UDP each retry takes the time determined by the timeo
315 and retrans options, which by default will be about 7
316 seconds. For TCP the default is 3 minutes, but system
317 TCP connection timeouts will sometimes limit the timeout
318 of each retransmission to around 2 minutes.
319 sec=flavors A colon-separated list of one or more security flavors
321 to use for accessing files on the mounted export. If the
322 server does not support any of these flavors, the mount
323 operation fails. If sec= is not specified, the client
324 attempts to find a security flavor that both the client
325 and the server supports. Valid flavors are none, sys,
326 krb5, krb5i, and krb5p. Refer to the SECURITY CONSIDER‐
327 ATIONS section for details.
328 sharecache / nosharecache
330 Determines how the client's data cache and attribute
331 cache are shared when mounting the same export more than
332 once concurrently. Using the same cache reduces memory
333 requirements on the client and presents identical file
334 contents to applications when the same remote file is
335 accessed via different mount points.
336 If neither option is specified, or if the sharecache op‐
338 tion is specified, then a single cache is used for all
339 mount points that access the same export. If the
340 nosharecache option is specified, then that mount point
341 gets a unique cache. Note that when data and attribute
342 caches are shared, the mount options from the first
343 mount point take effect for subsequent concurrent mounts
344 of the same export.
345 As of kernel 2.6.18, the behavior specified by noshare‐
347 cache is legacy caching behavior. This is considered a
348 data risk since multiple cached copies of the same file
349 on the same client can become out of sync following a
350 local update of one of the copies.
351 resvport / noresvport
353 Specifies whether the NFS client should use a privileged
354 source port when communicating with an NFS server for
355 this mount point. If this option is not specified, or
356 the resvport option is specified, the NFS client uses a
357 privileged source port. If the noresvport option is
358 specified, the NFS client uses a non-privileged source
359 port. This option is supported in kernels 2.6.28 and
360 later.
361 Using non-privileged source ports helps increase the
363 maximum number of NFS mount points allowed on a client,
364 but NFS servers must be configured to allow clients to
365 connect via non-privileged source ports.
366 Refer to the SECURITY CONSIDERATIONS section for impor‐
368 tant details.
369 lookupcache=mode
371 Specifies how the kernel manages its cache of directory
372 entries for a given mount point. mode can be one of
373 all, none, pos, or positive. This option is supported
374 in kernels 2.6.28 and later.
375 The Linux NFS client caches the result of all NFS LOOKUP
377 requests. If the requested directory entry exists on
378 the server, the result is referred to as positive. If
379 the requested directory entry does not exist on the
380 server, the result is referred to as negative.
381 If this option is not specified, or if all is specified,
383 the client assumes both types of directory cache entries
384 are valid until their parent directory's cached at‐
385 tributes expire.
386 If pos or positive is specified, the client assumes pos‐
388 itive entries are valid until their parent directory's
389 cached attributes expire, but always revalidates nega‐
390 tive entires before an application can use them.
391 If none is specified, the client revalidates both types
393 of directory cache entries before an application can use
394 them. This permits quick detection of files that were
395 created or removed by other clients, but can impact ap‐
396 plication and server performance.
397 The DATA AND METADATA COHERENCE section contains a de‐
399 tailed discussion of these trade-offs.
400 fsc / nofsc Enable/Disables the cache of (read-only) data pages to
402 the local disk using the FS-Cache facility. See
403 cachefilesd(8) and <kernel_source>/Documenta‐
404 tion/filesystems/caching for detail on how to configure
405 the FS-Cache facility. Default value is nofsc.
406 sloppy The sloppy option is an alternative to specifying
408 mount.nfs -s option.
409 Options for NFS versions 2 and 3 only
412 Use these options, along with the options in the above subsection, for
413 NFS versions 2 and 3 only.
414 proto=netid The netid determines the transport that is used to com‐
416 municate with the NFS server. Available options are
417 udp, udp6, tcp, tcp6, rdma, and rdma6. Those which end
418 in 6 use IPv6 addresses and are only available if sup‐
419 port for TI-RPC is built in. Others use IPv4 addresses.
420 Each transport protocol uses different default retrans
422 and timeo settings. Refer to the description of these
423 two mount options for details.
424 In addition to controlling how the NFS client transmits
426 requests to the server, this mount option also controls
427 how the mount(8) command communicates with the server's
428 rpcbind and mountd services. Specifying a netid that
429 uses TCP forces all traffic from the mount(8) command
430 and the NFS client to use TCP. Specifying a netid that
431 uses UDP forces all traffic types to use UDP.
432 Before using NFS over UDP, refer to the TRANSPORT METH‐
434 ODS section.
435 If the proto mount option is not specified, the mount(8)
437 command discovers which protocols the server supports
438 and chooses an appropriate transport for each service.
439 Refer to the TRANSPORT METHODS section for more details.
440 udp The udp option is an alternative to specifying
442 proto=udp. It is included for compatibility with other
443 operating systems.
444 Before using NFS over UDP, refer to the TRANSPORT METH‐
446 ODS section.
447 tcp The tcp option is an alternative to specifying
449 proto=tcp. It is included for compatibility with other
450 operating systems.
451 rdma The rdma option is an alternative to specifying
453 proto=rdma.
454 port=n The numeric value of the server's NFS service port. If
456 the server's NFS service is not available on the speci‐
457 fied port, the mount request fails.
458 If this option is not specified, or if the specified
460 port value is 0, then the NFS client uses the NFS ser‐
461 vice port number advertised by the server's rpcbind ser‐
462 vice. The mount request fails if the server's rpcbind
463 service is not available, the server's NFS service is
464 not registered with its rpcbind service, or the server's
465 NFS service is not available on the advertised port.
466 mountport=n The numeric value of the server's mountd port. If the
468 server's mountd service is not available on the speci‐
469 fied port, the mount request fails.
470 If this option is not specified, or if the specified
472 port value is 0, then the mount(8) command uses the
473 mountd service port number advertised by the server's
474 rpcbind service. The mount request fails if the
475 server's rpcbind service is not available, the server's
476 mountd service is not registered with its rpcbind ser‐
477 vice, or the server's mountd service is not available on
478 the advertised port.
479 This option can be used when mounting an NFS server
481 through a firewall that blocks the rpcbind protocol.
482 mountproto=netid
484 The transport the NFS client uses to transmit requests
485 to the NFS server's mountd service when performing this
486 mount request, and when later unmounting this mount
487 point.
488 netid may be one of udp, and tcp which use IPv4 address
490 or, if TI-RPC is built into the mount.nfs command, udp6,
491 and tcp6 which use IPv6 addresses.
492 This option can be used when mounting an NFS server
494 through a firewall that blocks a particular transport.
495 When used in combination with the proto option, differ‐
496 ent transports for mountd requests and NFS requests can
497 be specified. If the server's mountd service is not
498 available via the specified transport, the mount request
499 fails.
500 Refer to the TRANSPORT METHODS section for more on how
502 the mountproto mount option interacts with the proto
503 mount option.
504 mounthost=name The hostname of the host running mountd. If this option
506 is not specified, the mount(8) command assumes that the
507 mountd service runs on the same host as the NFS service.
508 mountvers=n The RPC version number used to contact the server's
510 mountd. If this option is not specified, the client
511 uses a version number appropriate to the requested NFS
512 version. This option is useful when multiple NFS ser‐
513 vices are running on the same remote server host.
514 namlen=n The maximum length of a pathname component on this
516 mount. If this option is not specified, the maximum
517 length is negotiated with the server. In most cases,
518 this maximum length is 255 characters.
519 Some early versions of NFS did not support this negotia‐
521 tion. Using this option ensures that pathconf(3) re‐
522 ports the proper maximum component length to applica‐
523 tions in such cases.
524 lock / nolock Selects whether to use the NLM sideband protocol to lock
526 files on the server. If neither option is specified (or
527 if lock is specified), NLM locking is used for this
528 mount point. When using the nolock option, applications
529 can lock files, but such locks provide exclusion only
530 against other applications running on the same client.
531 Remote applications are not affected by these locks.
532 NLM locking must be disabled with the nolock option when
534 using NFS to mount /var because /var contains files used
535 by the NLM implementation on Linux. Using the nolock
536 option is also required when mounting exports on NFS
537 servers that do not support the NLM protocol.
538 cto / nocto Selects whether to use close-to-open cache coherence se‐
540 mantics. If neither option is specified (or if cto is
541 specified), the client uses close-to-open cache coher‐
542 ence semantics. If the nocto option is specified, the
543 client uses a non-standard heuristic to determine when
544 files on the server have changed.
545 Using the nocto option may improve performance for read-
547 only mounts, but should be used only if the data on the
548 server changes only occasionally. The DATA AND METADATA
549 COHERENCE section discusses the behavior of this option
550 in more detail.
551 acl / noacl Selects whether to use the NFSACL sideband protocol on
553 this mount point. The NFSACL sideband protocol is a
554 proprietary protocol implemented in Solaris that manages
555 Access Control Lists. NFSACL was never made a standard
556 part of the NFS protocol specification.
557 If neither acl nor noacl option is specified, the NFS
559 client negotiates with the server to see if the NFSACL
560 protocol is supported, and uses it if the server sup‐
561 ports it. Disabling the NFSACL sideband protocol may be
562 necessary if the negotiation causes problems on the
563 client or server. Refer to the SECURITY CONSIDERATIONS
564 section for more details.
565 local_lock=mechanism
567 Specifies whether to use local locking for any or both
568 of the flock and the POSIX locking mechanisms. mecha‐
569 nism can be one of all, flock, posix, or none. This op‐
570 tion is supported in kernels 2.6.37 and later.
571 The Linux NFS client provides a way to make locks local.
573 This means, the applications can lock files, but such
574 locks provide exclusion only against other applications
575 running on the same client. Remote applications are not
576 affected by these locks.
577 If this option is not specified, or if none is speci‐
579 fied, the client assumes that the locks are not local.
580 If all is specified, the client assumes that both flock
582 and POSIX locks are local.
583 If flock is specified, the client assumes that only
585 flock locks are local and uses NLM sideband protocol to
586 lock files when POSIX locks are used.
587 If posix is specified, the client assumes that POSIX
589 locks are local and uses NLM sideband protocol to lock
590 files when flock locks are used.
591 To support legacy flock behavior similar to that of NFS
593 clients < 2.6.12, use 'local_lock=flock'. This option is
594 required when exporting NFS mounts via Samba as Samba
595 maps Windows share mode locks as flock. Since NFS
596 clients > 2.6.12 implement flock by emulating POSIX
597 locks, this will result in conflicting locks.
598 NOTE: When used together, the 'local_lock' mount option
600 will be overridden by 'nolock'/'lock' mount option.
601 Options for NFS version 4 only
603 Use these options, along with the options in the first subsection
604 above, for NFS version 4.0 and newer.
605 proto=netid The netid determines the transport that is used to com‐
607 municate with the NFS server. Supported options are
608 tcp, tcp6, rdma, and rdma6. tcp6 use IPv6 addresses and
609 is only available if support for TI-RPC is built in.
610 Both others use IPv4 addresses.
611 All NFS version 4 servers are required to support TCP,
613 so if this mount option is not specified, the NFS ver‐
614 sion 4 client uses the TCP protocol. Refer to the
615 TRANSPORT METHODS section for more details.
616 minorversion=n Specifies the protocol minor version number. NFSv4 in‐
618 troduces "minor versioning," where NFS protocol enhance‐
619 ments can be introduced without bumping the NFS protocol
620 version number. Before kernel 2.6.38, the minor version
621 is always zero, and this option is not recognized. Af‐
622 ter this kernel, specifying "minorversion=1" enables a
623 number of advanced features, such as NFSv4 sessions.
624 Recent kernels allow the minor version to be specified
626 using the vers= option. For example, specifying
627 vers=4.1 is the same as specifying vers=4,minorver‐
628 sion=1.
629 port=n The numeric value of the server's NFS service port. If
631 the server's NFS service is not available on the speci‐
632 fied port, the mount request fails.
633 If this mount option is not specified, the NFS client
635 uses the standard NFS port number of 2049 without first
636 checking the server's rpcbind service. This allows an
637 NFS version 4 client to contact an NFS version 4 server
638 through a firewall that may block rpcbind requests.
639 If the specified port value is 0, then the NFS client
641 uses the NFS service port number advertised by the
642 server's rpcbind service. The mount request fails if
643 the server's rpcbind service is not available, the
644 server's NFS service is not registered with its rpcbind
645 service, or the server's NFS service is not available on
646 the advertised port.
647 cto / nocto Selects whether to use close-to-open cache coherence se‐
649 mantics for NFS directories on this mount point. If
650 neither cto nor nocto is specified, the default is to
651 use close-to-open cache coherence semantics for directo‐
652 ries.
653 File data caching behavior is not affected by this op‐
655 tion. The DATA AND METADATA COHERENCE section discusses
656 the behavior of this option in more detail.
657 clientaddr=n.n.n.n
659 clientaddr=n:n:...:n
661 Specifies a single IPv4 address (in dotted-quad form),
662 or a non-link-local IPv6 address, that the NFS client
663 advertises to allow servers to perform NFS version 4.0
664 callback requests against files on this mount point. If
665 the server is unable to establish callback connections
666 to clients, performance may degrade, or accesses to
667 files may temporarily hang. Can specify a value of
668 IPv4_ANY (0.0.0.0) or equivalent IPv6 any address which
669 will signal to the NFS server that this NFS client does
670 not want delegations.
671 If this option is not specified, the mount(8) command
673 attempts to discover an appropriate callback address au‐
674 tomatically. The automatic discovery process is not
675 perfect, however. In the presence of multiple client
676 network interfaces, special routing policies, or atypi‐
677 cal network topologies, the exact address to use for
678 callbacks may be nontrivial to determine.
679 NFS protocol versions 4.1 and 4.2 use the client-estab‐
681 lished TCP connection for callback requests, so do not
682 require the server to connect to the client. This op‐
683 tion is therefore only affect NFS version 4.0 mounts.
684 migration / nomigration
686 Selects whether the client uses an identification string
687 that is compatible with NFSv4 Transparent State Migra‐
688 tion (TSM). If the mounted server supports NFSv4 migra‐
689 tion with TSM, specify the migration option.
690 Some server features misbehave in the face of a migra‐
692 tion-compatible identification string. The nomigration
693 option retains the use of a traditional client indenti‐
694 fication string which is compatible with legacy NFS
695 servers. This is also the behavior if neither option is
696 specified. A client's open and lock state cannot be mi‐
697 grated transparently when it identifies itself via a
698 traditional identification string.
699 This mount option has no effect with NFSv4 minor ver‐
701 sions newer than zero, which always use TSM-compatible
702 client identification strings.
703
705 The nfs4 file system type is an old syntax for specifying NFSv4 usage.
706 It can still be used with all NFSv4-specific and common options, ex‐
707 cepted the nfsvers mount option.
708
710 If the mount command is configured to do so, all of the mount options
711 described in the previous section can also be configured in the
712 /etc/nfsmount.conf file. See nfsmount.conf(5) for details.
713
715 To mount an export using NFS version 2, use the nfs file system type
716 and specify the nfsvers=2 mount option. To mount using NFS version 3,
717 use the nfs file system type and specify the nfsvers=3 mount option.
718 To mount using NFS version 4, use either the nfs file system type, with
719 the nfsvers=4 mount option, or the nfs4 file system type.
720 The following example from an /etc/fstab file causes the mount command
722 to negotiate reasonable defaults for NFS behavior.
723 server:/export /mnt nfs defaults 0 0
725 Here is an example from an /etc/fstab file for an NFS version 2 mount
727 over UDP.
728 server:/export /mnt nfs nfsvers=2,proto=udp 0 0
730 This example shows how to mount using NFS version 4 over TCP with Ker‐
732 beros 5 mutual authentication.
733 server:/export /mnt nfs4 sec=krb5 0 0
735 This example shows how to mount using NFS version 4 over TCP with Ker‐
737 beros 5 privacy or data integrity mode.
738 server:/export /mnt nfs4 sec=krb5p:krb5i 0 0
740 This example can be used to mount /usr over NFS.
742 server:/export /usr nfs ro,nolock,nocto,actimeo=3600 0 0
744 This example shows how to mount an NFS server using a raw IPv6 link-lo‐
746 cal address.
747 [fe80::215:c5ff:fb3e:e2b1%eth0]:/export /mnt nfs defaults 0 0
749
751 NFS clients send requests to NFS servers via Remote Procedure Calls, or
752 RPCs. The RPC client discovers remote service endpoints automatically,
753 handles per-request authentication, adjusts request parameters for dif‐
754 ferent byte endianness on client and server, and retransmits requests
755 that may have been lost by the network or server. RPC requests and
756 replies flow over a network transport.
757 In most cases, the mount(8) command, NFS client, and NFS server can au‐
759 tomatically negotiate proper transport and data transfer size settings
760 for a mount point. In some cases, however, it pays to specify these
761 settings explicitly using mount options.
762 Traditionally, NFS clients used the UDP transport exclusively for
764 transmitting requests to servers. Though its implementation is simple,
765 NFS over UDP has many limitations that prevent smooth operation and
766 good performance in some common deployment environments. Even an in‐
767 significant packet loss rate results in the loss of whole NFS requests;
768 as such, retransmit timeouts are usually in the subsecond range to al‐
769 low clients to recover quickly from dropped requests, but this can re‐
770 sult in extraneous network traffic and server load.
771 However, UDP can be quite effective in specialized settings where the
773 networks MTU is large relative to NFSs data transfer size (such as net‐
774 work environments that enable jumbo Ethernet frames). In such environ‐
775 ments, trimming the rsize and wsize settings so that each NFS read or
776 write request fits in just a few network frames (or even in a single
777 frame) is advised. This reduces the probability that the loss of a
778 single MTU-sized network frame results in the loss of an entire large
779 read or write request.
780 TCP is the default transport protocol used for all modern NFS implemen‐
782 tations. It performs well in almost every conceivable network environ‐
783 ment and provides excellent guarantees against data corruption caused
784 by network unreliability. TCP is often a requirement for mounting a
785 server through a network firewall.
786 Under normal circumstances, networks drop packets much more frequently
788 than NFS servers drop requests. As such, an aggressive retransmit
789 timeout setting for NFS over TCP is unnecessary. Typical timeout set‐
790 tings for NFS over TCP are between one and ten minutes. After the
791 client exhausts its retransmits (the value of the retrans mount op‐
792 tion), it assumes a network partition has occurred, and attempts to re‐
793 connect to the server on a fresh socket. Since TCP itself makes network
794 data transfer reliable, rsize and wsize can safely be allowed to de‐
795 fault to the largest values supported by both client and server, inde‐
796 pendent of the network's MTU size.
797 Using the mountproto mount option
799 This section applies only to NFS version 2 and version 3 mounts since
800 NFS version 4 does not use a separate protocol for mount requests.
801 The Linux NFS client can use a different transport for contacting an
803 NFS server's rpcbind service, its mountd service, its Network Lock Man‐
804 ager (NLM) service, and its NFS service. The exact transports employed
805 by the Linux NFS client for each mount point depends on the settings of
806 the transport mount options, which include proto, mountproto, udp, and
807 tcp.
808 The client sends Network Status Manager (NSM) notifications via UDP no
810 matter what transport options are specified, but listens for server NSM
811 notifications on both UDP and TCP. The NFS Access Control List (NF‐
812 SACL) protocol shares the same transport as the main NFS service.
813 If no transport options are specified, the Linux NFS client uses UDP to
815 contact the server's mountd service, and TCP to contact its NLM and NFS
816 services by default.
817 If the server does not support these transports for these services, the
819 mount(8) command attempts to discover what the server supports, and
820 then retries the mount request once using the discovered transports.
821 If the server does not advertise any transport supported by the client
822 or is misconfigured, the mount request fails. If the bg option is in
823 effect, the mount command backgrounds itself and continues to attempt
824 the specified mount request.
825 When the proto option, the udp option, or the tcp option is specified
827 but the mountproto option is not, the specified transport is used to
828 contact both the server's mountd service and for the NLM and NFS ser‐
829 vices.
830 If the mountproto option is specified but none of the proto, udp or tcp
832 options are specified, then the specified transport is used for the
833 initial mountd request, but the mount command attempts to discover what
834 the server supports for the NFS protocol, preferring TCP if both trans‐
835 ports are supported.
836 If both the mountproto and proto (or udp or tcp) options are specified,
838 then the transport specified by the mountproto option is used for the
839 initial mountd request, and the transport specified by the proto option
840 (or the udp or tcp options) is used for NFS, no matter what order these
841 options appear. No automatic service discovery is performed if these
842 options are specified.
843 If any of the proto, udp, tcp, or mountproto options are specified more
845 than once on the same mount command line, then the value of the right‐
846 most instance of each of these options takes effect.
847 Using NFS over UDP on high-speed links
849 Using NFS over UDP on high-speed links such as Gigabit can cause silent
850 data corruption.
851 The problem can be triggered at high loads, and is caused by problems
853 in IP fragment reassembly. NFS read and writes typically transmit UDP
854 packets of 4 Kilobytes or more, which have to be broken up into several
855 fragments in order to be sent over the Ethernet link, which limits
856 packets to 1500 bytes by default. This process happens at the IP net‐
857 work layer and is called fragmentation.
858 In order to identify fragments that belong together, IP assigns a 16bit
860 IP ID value to each packet; fragments generated from the same UDP
861 packet will have the same IP ID. The receiving system will collect
862 these fragments and combine them to form the original UDP packet. This
863 process is called reassembly. The default timeout for packet reassembly
864 is 30 seconds; if the network stack does not receive all fragments of a
865 given packet within this interval, it assumes the missing fragment(s)
866 got lost and discards those it already received.
867 The problem this creates over high-speed links is that it is possible
869 to send more than 65536 packets within 30 seconds. In fact, with heavy
870 NFS traffic one can observe that the IP IDs repeat after about 5 sec‐
871 onds.
872 This has serious effects on reassembly: if one fragment gets lost, an‐
874 other fragment from a different packet but with the same IP ID will ar‐
875 rive within the 30 second timeout, and the network stack will combine
876 these fragments to form a new packet. Most of the time, network layers
877 above IP will detect this mismatched reassembly - in the case of UDP,
878 the UDP checksum, which is a 16 bit checksum over the entire packet
879 payload, will usually not match, and UDP will discard the bad packet.
880 However, the UDP checksum is 16 bit only, so there is a chance of 1 in
882 65536 that it will match even if the packet payload is completely ran‐
883 dom (which very often isn't the case). If that is the case, silent data
884 corruption will occur.
885 This potential should be taken seriously, at least on Gigabit Ethernet.
887 Network speeds of 100Mbit/s should be considered less problematic, be‐
888 cause with most traffic patterns IP ID wrap around will take much
889 longer than 30 seconds.
890 It is therefore strongly recommended to use NFS over TCP where possi‐
892 ble, since TCP does not perform fragmentation.
893 If you absolutely have to use NFS over UDP over Gigabit Ethernet, some
895 steps can be taken to mitigate the problem and reduce the probability
896 of corruption:
897 Jumbo frames: Many Gigabit network cards are capable of transmitting
899 frames bigger than the 1500 byte limit of traditional
900 Ethernet, typically 9000 bytes. Using jumbo frames of
901 9000 bytes will allow you to run NFS over UDP at a page
902 size of 8K without fragmentation. Of course, this is
903 only feasible if all involved stations support jumbo
904 frames.
905 To enable a machine to send jumbo frames on cards that
907 support it, it is sufficient to configure the interface
908 for a MTU value of 9000.
909 Lower reassembly timeout:
911 By lowering this timeout below the time it takes the IP
912 ID counter to wrap around, incorrect reassembly of frag‐
913 ments can be prevented as well. To do so, simply write
914 the new timeout value (in seconds) to the file
915 /proc/sys/net/ipv4/ipfrag_time.
916 A value of 2 seconds will greatly reduce the probability
918 of IPID clashes on a single Gigabit link, while still
919 allowing for a reasonable timeout when receiving frag‐
920 mented traffic from distant peers.
921
923 Some modern cluster file systems provide perfect cache coherence among
924 their clients. Perfect cache coherence among disparate NFS clients is
925 expensive to achieve, especially on wide area networks. As such, NFS
926 settles for weaker cache coherence that satisfies the requirements of
927 most file sharing types.
928 Close-to-open cache consistency
930 Typically file sharing is completely sequential. First client A opens
931 a file, writes something to it, then closes it. Then client B opens
932 the same file, and reads the changes.
933 When an application opens a file stored on an NFS version 3 server, the
935 NFS client checks that the file exists on the server and is permitted
936 to the opener by sending a GETATTR or ACCESS request. The NFS client
937 sends these requests regardless of the freshness of the file's cached
938 attributes.
939 When the application closes the file, the NFS client writes back any
941 pending changes to the file so that the next opener can view the
942 changes. This also gives the NFS client an opportunity to report write
943 errors to the application via the return code from close(2).
944 The behavior of checking at open time and flushing at close time is re‐
946 ferred to as close-to-open cache consistency, or CTO. It can be dis‐
947 abled for an entire mount point using the nocto mount option.
948 Weak cache consistency
950 There are still opportunities for a client's data cache to contain
951 stale data. The NFS version 3 protocol introduced "weak cache consis‐
952 tency" (also known as WCC) which provides a way of efficiently checking
953 a file's attributes before and after a single request. This allows a
954 client to help identify changes that could have been made by other
955 clients.
956 When a client is using many concurrent operations that update the same
958 file at the same time (for example, during asynchronous write behind),
959 it is still difficult to tell whether it was that client's updates or
960 some other client's updates that altered the file.
961 Attribute caching
963 Use the noac mount option to achieve attribute cache coherence among
964 multiple clients. Almost every file system operation checks file at‐
965 tribute information. The client keeps this information cached for a
966 period of time to reduce network and server load. When noac is in ef‐
967 fect, a client's file attribute cache is disabled, so each operation
968 that needs to check a file's attributes is forced to go back to the
969 server. This permits a client to see changes to a file very quickly,
970 at the cost of many extra network operations.
971 Be careful not to confuse the noac option with "no data caching." The
973 noac mount option prevents the client from caching file metadata, but
974 there are still races that may result in data cache incoherence between
975 client and server.
976 The NFS protocol is not designed to support true cluster file system
978 cache coherence without some type of application serialization. If ab‐
979 solute cache coherence among clients is required, applications should
980 use file locking. Alternatively, applications can also open their files
981 with the O_DIRECT flag to disable data caching entirely.
982 File timestamp maintenance
984 NFS servers are responsible for managing file and directory timestamps
985 (atime, ctime, and mtime). When a file is accessed or updated on an
986 NFS server, the file's timestamps are updated just like they would be
987 on a filesystem local to an application.
988 NFS clients cache file attributes, including timestamps. A file's
990 timestamps are updated on NFS clients when its attributes are retrieved
991 from the NFS server. Thus there may be some delay before timestamp up‐
992 dates on an NFS server appear to applications on NFS clients.
993 To comply with the POSIX filesystem standard, the Linux NFS client re‐
995 lies on NFS servers to keep a file's mtime and ctime timestamps prop‐
996 erly up to date. It does this by flushing local data changes to the
997 server before reporting mtime to applications via system calls such as
998 stat(2).
999 The Linux client handles atime updates more loosely, however. NFS
1001 clients maintain good performance by caching data, but that means that
1002 application reads, which normally update atime, are not reflected to
1003 the server where a file's atime is actually maintained.
1004 Because of this caching behavior, the Linux NFS client does not support
1006 generic atime-related mount options. See mount(8) for details on these
1007 options.
1008 In particular, the atime/noatime, diratime/nodiratime, relatime/norela‐
1010 time, and strictatime/nostrictatime mount options have no effect on NFS
1011 mounts.
1012 /proc/mounts may report that the relatime mount option is set on NFS
1014 mounts, but in fact the atime semantics are always as described here,
1015 and are not like relatime semantics.
1016 Directory entry caching
1018 The Linux NFS client caches the result of all NFS LOOKUP requests. If
1019 the requested directory entry exists on the server, the result is re‐
1020 ferred to as a positive lookup result. If the requested directory en‐
1021 try does not exist on the server (that is, the server returned ENOENT),
1022 the result is referred to as negative lookup result.
1023 To detect when directory entries have been added or removed on the
1025 server, the Linux NFS client watches a directory's mtime. If the
1026 client detects a change in a directory's mtime, the client drops all
1027 cached LOOKUP results for that directory. Since the directory's mtime
1028 is a cached attribute, it may take some time before a client notices it
1029 has changed. See the descriptions of the acdirmin, acdirmax, and noac
1030 mount options for more information about how long a directory's mtime
1031 is cached.
1032 Caching directory entries improves the performance of applications that
1034 do not share files with applications on other clients. Using cached
1035 information about directories can interfere with applications that run
1036 concurrently on multiple clients and need to detect the creation or re‐
1037 moval of files quickly, however. The lookupcache mount option allows
1038 some tuning of directory entry caching behavior.
1039 Before kernel release 2.6.28, the Linux NFS client tracked only posi‐
1041 tive lookup results. This permitted applications to detect new direc‐
1042 tory entries created by other clients quickly while still providing
1043 some of the performance benefits of caching. If an application depends
1044 on the previous lookup caching behavior of the Linux NFS client, you
1045 can use lookupcache=positive.
1046 If the client ignores its cache and validates every application lookup
1048 request with the server, that client can immediately detect when a new
1049 directory entry has been either created or removed by another client.
1050 You can specify this behavior using lookupcache=none. The extra NFS
1051 requests needed if the client does not cache directory entries can ex‐
1052 act a performance penalty. Disabling lookup caching should result in
1053 less of a performance penalty than using noac, and has no effect on how
1054 the NFS client caches the attributes of files.
1055 The sync mount option
1057 The NFS client treats the sync mount option differently than some other
1058 file systems (refer to mount(8) for a description of the generic sync
1059 and async mount options). If neither sync nor async is specified (or
1060 if the async option is specified), the NFS client delays sending appli‐
1061 cation writes to the server until any of these events occur:
1062 Memory pressure forces reclamation of system memory resources.
1064 An application flushes file data explicitly with sync(2),
1066 msync(2), or fsync(3).
1067 An application closes a file with close(2).
1069 The file is locked/unlocked via fcntl(2).
1071 In other words, under normal circumstances, data written by an applica‐
1073 tion may not immediately appear on the server that hosts the file.
1074 If the sync option is specified on a mount point, any system call that
1076 writes data to files on that mount point causes that data to be flushed
1077 to the server before the system call returns control to user space.
1078 This provides greater data cache coherence among clients, but at a sig‐
1079 nificant performance cost.
1080 Applications can use the O_SYNC open flag to force application writes
1082 to individual files to go to the server immediately without the use of
1083 the sync mount option.
1084 Using file locks with NFS
1086 The Network Lock Manager protocol is a separate sideband protocol used
1087 to manage file locks in NFS version 2 and version 3. To support lock
1088 recovery after a client or server reboot, a second sideband protocol --
1089 known as the Network Status Manager protocol -- is also required. In
1090 NFS version 4, file locking is supported directly in the main NFS pro‐
1091 tocol, and the NLM and NSM sideband protocols are not used.
1092 In most cases, NLM and NSM services are started automatically, and no
1094 extra configuration is required. Configure all NFS clients with fully-
1095 qualified domain names to ensure that NFS servers can find clients to
1096 notify them of server reboots.
1097 NLM supports advisory file locks only. To lock NFS files, use fcntl(2)
1099 with the F_GETLK and F_SETLK commands. The NFS client converts file
1100 locks obtained via flock(2) to advisory locks.
1101 When mounting servers that do not support the NLM protocol, or when
1103 mounting an NFS server through a firewall that blocks the NLM service
1104 port, specify the nolock mount option. NLM locking must be disabled
1105 with the nolock option when using NFS to mount /var because /var con‐
1106 tains files used by the NLM implementation on Linux.
1107 Specifying the nolock option may also be advised to improve the perfor‐
1109 mance of a proprietary application which runs on a single client and
1110 uses file locks extensively.
1111 NFS version 4 caching features
1113 The data and metadata caching behavior of NFS version 4 clients is sim‐
1114 ilar to that of earlier versions. However, NFS version 4 adds two fea‐
1115 tures that improve cache behavior: change attributes and file delega‐
1116 tion.
1117 The change attribute is a new part of NFS file and directory metadata
1119 which tracks data changes. It replaces the use of a file's modifica‐
1120 tion and change time stamps as a way for clients to validate the con‐
1121 tent of their caches. Change attributes are independent of the time
1122 stamp resolution on either the server or client, however.
1123 A file delegation is a contract between an NFS version 4 client and
1125 server that allows the client to treat a file temporarily as if no
1126 other client is accessing it. The server promises to notify the client
1127 (via a callback request) if another client attempts to access that
1128 file. Once a file has been delegated to a client, the client can cache
1129 that file's data and metadata aggressively without contacting the
1130 server.
1131 File delegations come in two flavors: read and write. A read delega‐
1133 tion means that the server notifies the client about any other clients
1134 that want to write to the file. A write delegation means that the
1135 client gets notified about either read or write accessors.
1136 Servers grant file delegations when a file is opened, and can recall
1138 delegations at any time when another client wants access to the file
1139 that conflicts with any delegations already granted. Delegations on
1140 directories are not supported.
1141 In order to support delegation callback, the server checks the network
1143 return path to the client during the client's initial contact with the
1144 server. If contact with the client cannot be established, the server
1145 simply does not grant any delegations to that client.
1146
1148 NFS servers control access to file data, but they depend on their RPC
1149 implementation to provide authentication of NFS requests. Traditional
1150 NFS access control mimics the standard mode bit access control provided
1151 in local file systems. Traditional RPC authentication uses a number to
1152 represent each user (usually the user's own uid), a number to represent
1153 the user's group (the user's gid), and a set of up to 16 auxiliary
1154 group numbers to represent other groups of which the user may be a mem‐
1155 ber.
1156 Typically, file data and user ID values appear unencrypted (i.e. "in
1158 the clear") on the network. Moreover, NFS versions 2 and 3 use sepa‐
1159 rate sideband protocols for mounting, locking and unlocking files, and
1160 reporting system status of clients and servers. These auxiliary proto‐
1161 cols use no authentication.
1162 In addition to combining these sideband protocols with the main NFS
1164 protocol, NFS version 4 introduces more advanced forms of access con‐
1165 trol, authentication, and in-transit data protection. The NFS version
1166 4 specification mandates support for strong authentication and security
1167 flavors that provide per-RPC integrity checking and encryption. Be‐
1168 cause NFS version 4 combines the function of the sideband protocols
1169 into the main NFS protocol, the new security features apply to all NFS
1170 version 4 operations including mounting, file locking, and so on.
1171 RPCGSS authentication can also be used with NFS versions 2 and 3, but
1172 it does not protect their sideband protocols.
1173 The sec mount option specifies the security flavor used for operations
1175 on behalf of users on that NFS mount point. Specifying sec=krb5 pro‐
1176 vides cryptographic proof of a user's identity in each RPC request.
1177 This provides strong verification of the identity of users accessing
1178 data on the server. Note that additional configuration besides adding
1179 this mount option is required in order to enable Kerberos security.
1180 Refer to the rpc.gssd(8) man page for details.
1181 Two additional flavors of Kerberos security are supported: krb5i and
1183 krb5p. The krb5i security flavor provides a cryptographically strong
1184 guarantee that the data in each RPC request has not been tampered with.
1185 The krb5p security flavor encrypts every RPC request to prevent data
1186 exposure during network transit; however, expect some performance im‐
1187 pact when using integrity checking or encryption. Similar support for
1188 other forms of cryptographic security is also available.
1189 NFS version 4 filesystem crossing
1191 The NFS version 4 protocol allows a client to renegotiate the security
1192 flavor when the client crosses into a new filesystem on the server.
1193 The newly negotiated flavor effects only accesses of the new filesys‐
1194 tem.
1195 Such negotiation typically occurs when a client crosses from a server's
1197 pseudo-fs into one of the server's exported physical filesystems, which
1198 often have more restrictive security settings than the pseudo-fs.
1199 NFS version 4 Leases
1201 In NFS version 4, a lease is a period during which a server irrevocably
1202 grants a client file locks. Once the lease expires, the server may re‐
1203 voke those locks. Clients periodically renew their leases to prevent
1204 lock revocation.
1205 After an NFS version 4 server reboots, each client tells the server
1207 about existing file open and lock state under its lease before opera‐
1208 tion can continue. If a client reboots, the server frees all open and
1209 lock state associated with that client's lease.
1210 When establishing a lease, therefore, a client must identify itself to
1212 a server. Each client presents an arbitrary string to distinguish it‐
1213 self from other clients. The client administrator can supplement the
1214 default identity string using the nfs4.nfs4_unique_id module parameter
1215 to avoid collisions with other client identity strings.
1216 A client also uses a unique security flavor and principal when it es‐
1218 tablishes its lease. If two clients present the same identity string,
1219 a server can use client principals to distinguish between them, thus
1220 securely preventing one client from interfering with the other's lease.
1221 The Linux NFS client establishes one lease on each NFS version 4
1223 server. Lease management operations, such as lease renewal, are not
1224 done on behalf of a particular file, lock, user, or mount point, but on
1225 behalf of the client that owns that lease. A client uses a consistent
1226 identity string, security flavor, and principal across client reboots
1227 to ensure that the server can promptly reap expired lease state.
1228 When Kerberos is configured on a Linux NFS client (i.e., there is a
1230 /etc/krb5.keytab on that client), the client attempts to use a Kerberos
1231 security flavor for its lease management operations. Kerberos provides
1232 secure authentication of each client. By default, the client uses the
1233 host/ or nfs/ service principal in its /etc/krb5.keytab for this pur‐
1234 pose, as described in rpc.gssd(8).
1235 If the client has Kerberos configured, but the server does not, or if
1237 the client does not have a keytab or the requisite service principals,
1238 the client uses AUTH_SYS and UID 0 for lease management.
1239 Using non-privileged source ports
1241 NFS clients usually communicate with NFS servers via network sockets.
1242 Each end of a socket is assigned a port value, which is simply a number
1243 between 1 and 65535 that distinguishes socket endpoints at the same IP
1244 address. A socket is uniquely defined by a tuple that includes the
1245 transport protocol (TCP or UDP) and the port values and IP addresses of
1246 both endpoints.
1247 The NFS client can choose any source port value for its sockets, but
1249 usually chooses a privileged port. A privileged port is a port value
1250 less than 1024. Only a process with root privileges may create a
1251 socket with a privileged source port.
1252 The exact range of privileged source ports that can be chosen is set by
1254 a pair of sysctls to avoid choosing a well-known port, such as the port
1255 used by ssh. This means the number of source ports available for the
1256 NFS client, and therefore the number of socket connections that can be
1257 used at the same time, is practically limited to only a few hundred.
1258 As described above, the traditional default NFS authentication scheme,
1260 known as AUTH_SYS, relies on sending local UID and GID numbers to iden‐
1261 tify users making NFS requests. An NFS server assumes that if a con‐
1262 nection comes from a privileged port, the UID and GID numbers in the
1263 NFS requests on this connection have been verified by the client's ker‐
1264 nel or some other local authority. This is an easy system to spoof,
1265 but on a trusted physical network between trusted hosts, it is entirely
1266 adequate.
1267 Roughly speaking, one socket is used for each NFS mount point. If a
1269 client could use non-privileged source ports as well, the number of
1270 sockets allowed, and thus the maximum number of concurrent mount
1271 points, would be much larger.
1272 Using non-privileged source ports may compromise server security some‐
1274 what, since any user on AUTH_SYS mount points can now pretend to be any
1275 other when making NFS requests. Thus NFS servers do not support this
1276 by default. They explicitly allow it usually via an export option.
1277 To retain good security while allowing as many mount points as possi‐
1279 ble, it is best to allow non-privileged client connections only if the
1280 server and client both require strong authentication, such as Kerberos.
1281 Mounting through a firewall
1283 A firewall may reside between an NFS client and server, or the client
1284 or server may block some of its own ports via IP filter rules. It is
1285 still possible to mount an NFS server through a firewall, though some
1286 of the mount(8) command's automatic service endpoint discovery mecha‐
1287 nisms may not work; this requires you to provide specific endpoint de‐
1288 tails via NFS mount options.
1289 NFS servers normally run a portmapper or rpcbind daemon to advertise
1291 their service endpoints to clients. Clients use the rpcbind daemon to
1292 determine:
1293 What network port each RPC-based service is using
1295 What transport protocols each RPC-based service supports
1297 The rpcbind daemon uses a well-known port number (111) to help clients
1299 find a service endpoint. Although NFS often uses a standard port num‐
1300 ber (2049), auxiliary services such as the NLM service can choose any
1301 unused port number at random.
1302 Common firewall configurations block the well-known rpcbind port. In
1304 the absense of an rpcbind service, the server administrator fixes the
1305 port number of NFS-related services so that the firewall can allow ac‐
1306 cess to specific NFS service ports. Client administrators then specify
1307 the port number for the mountd service via the mount(8) command's
1308 mountport option. It may also be necessary to enforce the use of TCP
1309 or UDP if the firewall blocks one of those transports.
1310 NFS Access Control Lists
1312 Solaris allows NFS version 3 clients direct access to POSIX Access Con‐
1313 trol Lists stored in its local file systems. This proprietary sideband
1314 protocol, known as NFSACL, provides richer access control than mode
1315 bits. Linux implements this protocol for compatibility with the So‐
1316 laris NFS implementation. The NFSACL protocol never became a standard
1317 part of the NFS version 3 specification, however.
1318 The NFS version 4 specification mandates a new version of Access Con‐
1320 trol Lists that are semantically richer than POSIX ACLs. NFS version 4
1321 ACLs are not fully compatible with POSIX ACLs; as such, some transla‐
1322 tion between the two is required in an environment that mixes POSIX
1323 ACLs and NFS version 4.
1324
1326 Generic mount options such as rw and sync can be modified on NFS mount
1327 points using the remount option. See mount(8) for more information on
1328 generic mount options.
1329 With few exceptions, NFS-specific options are not able to be modified
1331 during a remount. The underlying transport or NFS version cannot be
1332 changed by a remount, for example.
1333 Performing a remount on an NFS file system mounted with the noac option
1335 may have unintended consequences. The noac option is a combination of
1336 the generic option sync, and the NFS-specific option actimeo=0.
1337 Unmounting after a remount
1339 For mount points that use NFS versions 2 or 3, the NFS umount subcom‐
1340 mand depends on knowing the original set of mount options used to per‐
1341 form the MNT operation. These options are stored on disk by the NFS
1342 mount subcommand, and can be erased by a remount.
1343 To ensure that the saved mount options are not erased during a remount,
1345 specify either the local mount directory, or the server hostname and
1346 export pathname, but not both, during a remount. For example,
1347 mount -o remount,ro /mnt
1349 merges the mount option ro with the mount options already saved on disk
1351 for the NFS server mounted at /mnt.
1352
1354 /etc/fstab file system table
1355 /etc/nfsmount.conf
1357 Configuration file for NFS mounts
1358
1360 Before 2.4.7, the Linux NFS client did not support NFS over TCP.
1361 Before 2.4.20, the Linux NFS client used a heuristic to determine
1363 whether cached file data was still valid rather than using the standard
1364 close-to-open cache coherency method described above.
1365 Starting with 2.4.22, the Linux NFS client employs a Van Jacobsen-based
1367 RTT estimator to determine retransmit timeout values when using NFS
1368 over UDP.
1369 Before 2.6.0, the Linux NFS client did not support NFS version 4.
1371 Before 2.6.8, the Linux NFS client used only synchronous reads and
1373 writes when the rsize and wsize settings were smaller than the system's
1374 page size.
1375 The Linux client's support for protocol versions depend on whether the
1377 kernel was built with options CONFIG_NFS_V2, CONFIG_NFS_V3, CON‐
1378 FIG_NFS_V4, CONFIG_NFS_V4_1, and CONFIG_NFS_V4_2.
1379
1381 fstab(5), mount(8), umount(8), mount.nfs(5), umount.nfs(5), exports(5),
1382 nfsmount.conf(5), netconfig(5), ipv6(7), nfsd(8), sm-notify(8),
1383 rpc.statd(8), rpc.idmapd(8), rpc.gssd(8), rpc.svcgssd(8), kerberos(1)
1384 RFC 768 for the UDP specification.
1386 RFC 793 for the TCP specification.
1387 RFC 1094 for the NFS version 2 specification.
1388 RFC 1813 for the NFS version 3 specification.
1389 RFC 1832 for the XDR specification.
1390 RFC 1833 for the RPC bind specification.
1391 RFC 2203 for the RPCSEC GSS API protocol specification.
1392 RFC 7530 for the NFS version 4.0 specification.
1393 RFC 5661 for the NFS version 4.1 specification.
1394 RFC 7862 for the NFS version 4.2 specification.
1395 9 October 2012 NFS(5)