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 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 mount option. To mount using NFS version 3, use the nfs file system
716 type and specify the nfsvers=3 mount option. To mount using NFS ver‐
717 sion 4, use either the nfs file system type, with the nfsvers=4 mount
718 option, or the nfs4 file system type.
719 The following example from an /etc/fstab file causes the mount command
721 to negotiate reasonable defaults for NFS behavior.
722 server:/export /mnt nfs defaults 0 0
724 This example shows how to mount using NFS version 4 over TCP with Ker‐
726 beros 5 mutual authentication.
727 server:/export /mnt nfs4 sec=krb5 0 0
729 This example shows how to mount using NFS version 4 over TCP with Ker‐
731 beros 5 privacy or data integrity mode.
732 server:/export /mnt nfs4 sec=krb5p:krb5i 0 0
734 This example can be used to mount /usr over NFS.
736 server:/export /usr nfs ro,nolock,nocto,actimeo=3600 0 0
738 This example shows how to mount an NFS server using a raw IPv6 link-lo‐
740 cal address.
741 [fe80::215:c5ff:fb3e:e2b1%eth0]:/export /mnt nfs defaults 0 0
743
745 NFS clients send requests to NFS servers via Remote Procedure Calls, or
746 RPCs. The RPC client discovers remote service endpoints automatically,
747 handles per-request authentication, adjusts request parameters for dif‐
748 ferent byte endianness on client and server, and retransmits requests
749 that may have been lost by the network or server. RPC requests and
750 replies flow over a network transport.
751 In most cases, the mount(8) command, NFS client, and NFS server can au‐
753 tomatically negotiate proper transport and data transfer size settings
754 for a mount point. In some cases, however, it pays to specify these
755 settings explicitly using mount options.
756 Traditionally, NFS clients used the UDP transport exclusively for
758 transmitting requests to servers. Though its implementation is simple,
759 NFS over UDP has many limitations that prevent smooth operation and
760 good performance in some common deployment environments. Even an in‐
761 significant packet loss rate results in the loss of whole NFS requests;
762 as such, retransmit timeouts are usually in the subsecond range to al‐
763 low clients to recover quickly from dropped requests, but this can re‐
764 sult in extraneous network traffic and server load.
765 However, UDP can be quite effective in specialized settings where the
767 networks MTU is large relative to NFSs data transfer size (such as net‐
768 work environments that enable jumbo Ethernet frames). In such environ‐
769 ments, trimming the rsize and wsize settings so that each NFS read or
770 write request fits in just a few network frames (or even in a single
771 frame) is advised. This reduces the probability that the loss of a
772 single MTU-sized network frame results in the loss of an entire large
773 read or write request.
774 TCP is the default transport protocol used for all modern NFS implemen‐
776 tations. It performs well in almost every conceivable network environ‐
777 ment and provides excellent guarantees against data corruption caused
778 by network unreliability. TCP is often a requirement for mounting a
779 server through a network firewall.
780 Under normal circumstances, networks drop packets much more frequently
782 than NFS servers drop requests. As such, an aggressive retransmit
783 timeout setting for NFS over TCP is unnecessary. Typical timeout set‐
784 tings for NFS over TCP are between one and ten minutes. After the
785 client exhausts its retransmits (the value of the retrans mount op‐
786 tion), it assumes a network partition has occurred, and attempts to re‐
787 connect to the server on a fresh socket. Since TCP itself makes network
788 data transfer reliable, rsize and wsize can safely be allowed to de‐
789 fault to the largest values supported by both client and server, inde‐
790 pendent of the network's MTU size.
791 Using the mountproto mount option
793 This section applies only to NFS version 3 mounts since NFS version 4
794 does not use a separate protocol for mount requests.
795 The Linux NFS client can use a different transport for contacting an
797 NFS server's rpcbind service, its mountd service, its Network Lock Man‐
798 ager (NLM) service, and its NFS service. The exact transports employed
799 by the Linux NFS client for each mount point depends on the settings of
800 the transport mount options, which include proto, mountproto, udp, and
801 tcp.
802 The client sends Network Status Manager (NSM) notifications via UDP no
804 matter what transport options are specified, but listens for server NSM
805 notifications on both UDP and TCP. The NFS Access Control List (NF‐
806 SACL) protocol shares the same transport as the main NFS service.
807 If no transport options are specified, the Linux NFS client uses UDP to
809 contact the server's mountd service, and TCP to contact its NLM and NFS
810 services by default.
811 If the server does not support these transports for these services, the
813 mount(8) command attempts to discover what the server supports, and
814 then retries the mount request once using the discovered transports.
815 If the server does not advertise any transport supported by the client
816 or is misconfigured, the mount request fails. If the bg option is in
817 effect, the mount command backgrounds itself and continues to attempt
818 the specified mount request.
819 When the proto option, the udp option, or the tcp option is specified
821 but the mountproto option is not, the specified transport is used to
822 contact both the server's mountd service and for the NLM and NFS ser‐
823 vices.
824 If the mountproto option is specified but none of the proto, udp or tcp
826 options are specified, then the specified transport is used for the
827 initial mountd request, but the mount command attempts to discover what
828 the server supports for the NFS protocol, preferring TCP if both trans‐
829 ports are supported.
830 If both the mountproto and proto (or udp or tcp) options are specified,
832 then the transport specified by the mountproto option is used for the
833 initial mountd request, and the transport specified by the proto option
834 (or the udp or tcp options) is used for NFS, no matter what order these
835 options appear. No automatic service discovery is performed if these
836 options are specified.
837 If any of the proto, udp, tcp, or mountproto options are specified more
839 than once on the same mount command line, then the value of the right‐
840 most instance of each of these options takes effect.
841 Using NFS over UDP on high-speed links
843 Using NFS over UDP on high-speed links such as Gigabit can cause silent
844 data corruption.
845 The problem can be triggered at high loads, and is caused by problems
847 in IP fragment reassembly. NFS read and writes typically transmit UDP
848 packets of 4 Kilobytes or more, which have to be broken up into several
849 fragments in order to be sent over the Ethernet link, which limits
850 packets to 1500 bytes by default. This process happens at the IP net‐
851 work layer and is called fragmentation.
852 In order to identify fragments that belong together, IP assigns a 16bit
854 IP ID value to each packet; fragments generated from the same UDP
855 packet will have the same IP ID. The receiving system will collect
856 these fragments and combine them to form the original UDP packet. This
857 process is called reassembly. The default timeout for packet reassembly
858 is 30 seconds; if the network stack does not receive all fragments of a
859 given packet within this interval, it assumes the missing fragment(s)
860 got lost and discards those it already received.
861 The problem this creates over high-speed links is that it is possible
863 to send more than 65536 packets within 30 seconds. In fact, with heavy
864 NFS traffic one can observe that the IP IDs repeat after about 5 sec‐
865 onds.
866 This has serious effects on reassembly: if one fragment gets lost, an‐
868 other fragment from a different packet but with the same IP ID will ar‐
869 rive within the 30 second timeout, and the network stack will combine
870 these fragments to form a new packet. Most of the time, network layers
871 above IP will detect this mismatched reassembly - in the case of UDP,
872 the UDP checksum, which is a 16 bit checksum over the entire packet
873 payload, will usually not match, and UDP will discard the bad packet.
874 However, the UDP checksum is 16 bit only, so there is a chance of 1 in
876 65536 that it will match even if the packet payload is completely ran‐
877 dom (which very often isn't the case). If that is the case, silent data
878 corruption will occur.
879 This potential should be taken seriously, at least on Gigabit Ethernet.
881 Network speeds of 100Mbit/s should be considered less problematic, be‐
882 cause with most traffic patterns IP ID wrap around will take much
883 longer than 30 seconds.
884 It is therefore strongly recommended to use NFS over TCP where possi‐
886 ble, since TCP does not perform fragmentation.
887 If you absolutely have to use NFS over UDP over Gigabit Ethernet, some
889 steps can be taken to mitigate the problem and reduce the probability
890 of corruption:
891 Jumbo frames: Many Gigabit network cards are capable of transmitting
893 frames bigger than the 1500 byte limit of traditional
894 Ethernet, typically 9000 bytes. Using jumbo frames of
895 9000 bytes will allow you to run NFS over UDP at a page
896 size of 8K without fragmentation. Of course, this is
897 only feasible if all involved stations support jumbo
898 frames.
899 To enable a machine to send jumbo frames on cards that
901 support it, it is sufficient to configure the interface
902 for a MTU value of 9000.
903 Lower reassembly timeout:
905 By lowering this timeout below the time it takes the IP
906 ID counter to wrap around, incorrect reassembly of frag‐
907 ments can be prevented as well. To do so, simply write
908 the new timeout value (in seconds) to the file
909 /proc/sys/net/ipv4/ipfrag_time.
910 A value of 2 seconds will greatly reduce the probability
912 of IPID clashes on a single Gigabit link, while still
913 allowing for a reasonable timeout when receiving frag‐
914 mented traffic from distant peers.
915
917 Some modern cluster file systems provide perfect cache coherence among
918 their clients. Perfect cache coherence among disparate NFS clients is
919 expensive to achieve, especially on wide area networks. As such, NFS
920 settles for weaker cache coherence that satisfies the requirements of
921 most file sharing types.
922 Close-to-open cache consistency
924 Typically file sharing is completely sequential. First client A opens
925 a file, writes something to it, then closes it. Then client B opens
926 the same file, and reads the changes.
927 When an application opens a file stored on an NFS version 3 server, the
929 NFS client checks that the file exists on the server and is permitted
930 to the opener by sending a GETATTR or ACCESS request. The NFS client
931 sends these requests regardless of the freshness of the file's cached
932 attributes.
933 When the application closes the file, the NFS client writes back any
935 pending changes to the file so that the next opener can view the
936 changes. This also gives the NFS client an opportunity to report write
937 errors to the application via the return code from close(2).
938 The behavior of checking at open time and flushing at close time is re‐
940 ferred to as close-to-open cache consistency, or CTO. It can be dis‐
941 abled for an entire mount point using the nocto mount option.
942 Weak cache consistency
944 There are still opportunities for a client's data cache to contain
945 stale data. The NFS version 3 protocol introduced "weak cache consis‐
946 tency" (also known as WCC) which provides a way of efficiently checking
947 a file's attributes before and after a single request. This allows a
948 client to help identify changes that could have been made by other
949 clients.
950 When a client is using many concurrent operations that update the same
952 file at the same time (for example, during asynchronous write behind),
953 it is still difficult to tell whether it was that client's updates or
954 some other client's updates that altered the file.
955 Attribute caching
957 Use the noac mount option to achieve attribute cache coherence among
958 multiple clients. Almost every file system operation checks file at‐
959 tribute information. The client keeps this information cached for a
960 period of time to reduce network and server load. When noac is in ef‐
961 fect, a client's file attribute cache is disabled, so each operation
962 that needs to check a file's attributes is forced to go back to the
963 server. This permits a client to see changes to a file very quickly,
964 at the cost of many extra network operations.
965 Be careful not to confuse the noac option with "no data caching." The
967 noac mount option prevents the client from caching file metadata, but
968 there are still races that may result in data cache incoherence between
969 client and server.
970 The NFS protocol is not designed to support true cluster file system
972 cache coherence without some type of application serialization. If ab‐
973 solute cache coherence among clients is required, applications should
974 use file locking. Alternatively, applications can also open their files
975 with the O_DIRECT flag to disable data caching entirely.
976 File timestamp maintenance
978 NFS servers are responsible for managing file and directory timestamps
979 (atime, ctime, and mtime). When a file is accessed or updated on an
980 NFS server, the file's timestamps are updated just like they would be
981 on a filesystem local to an application.
982 NFS clients cache file attributes, including timestamps. A file's
984 timestamps are updated on NFS clients when its attributes are retrieved
985 from the NFS server. Thus there may be some delay before timestamp up‐
986 dates on an NFS server appear to applications on NFS clients.
987 To comply with the POSIX filesystem standard, the Linux NFS client re‐
989 lies on NFS servers to keep a file's mtime and ctime timestamps prop‐
990 erly up to date. It does this by flushing local data changes to the
991 server before reporting mtime to applications via system calls such as
992 stat(2).
993 The Linux client handles atime updates more loosely, however. NFS
995 clients maintain good performance by caching data, but that means that
996 application reads, which normally update atime, are not reflected to
997 the server where a file's atime is actually maintained.
998 Because of this caching behavior, the Linux NFS client does not support
1000 generic atime-related mount options. See mount(8) for details on these
1001 options.
1002 In particular, the atime/noatime, diratime/nodiratime, relatime/norela‐
1004 time, and strictatime/nostrictatime mount options have no effect on NFS
1005 mounts.
1006 /proc/mounts may report that the relatime mount option is set on NFS
1008 mounts, but in fact the atime semantics are always as described here,
1009 and are not like relatime semantics.
1010 Directory entry caching
1012 The Linux NFS client caches the result of all NFS LOOKUP requests. If
1013 the requested directory entry exists on the server, the result is re‐
1014 ferred to as a positive lookup result. If the requested directory en‐
1015 try does not exist on the server (that is, the server returned ENOENT),
1016 the result is referred to as negative lookup result.
1017 To detect when directory entries have been added or removed on the
1019 server, the Linux NFS client watches a directory's mtime. If the
1020 client detects a change in a directory's mtime, the client drops all
1021 cached LOOKUP results for that directory. Since the directory's mtime
1022 is a cached attribute, it may take some time before a client notices it
1023 has changed. See the descriptions of the acdirmin, acdirmax, and noac
1024 mount options for more information about how long a directory's mtime
1025 is cached.
1026 Caching directory entries improves the performance of applications that
1028 do not share files with applications on other clients. Using cached
1029 information about directories can interfere with applications that run
1030 concurrently on multiple clients and need to detect the creation or re‐
1031 moval of files quickly, however. The lookupcache mount option allows
1032 some tuning of directory entry caching behavior.
1033 Before kernel release 2.6.28, the Linux NFS client tracked only posi‐
1035 tive lookup results. This permitted applications to detect new direc‐
1036 tory entries created by other clients quickly while still providing
1037 some of the performance benefits of caching. If an application depends
1038 on the previous lookup caching behavior of the Linux NFS client, you
1039 can use lookupcache=positive.
1040 If the client ignores its cache and validates every application lookup
1042 request with the server, that client can immediately detect when a new
1043 directory entry has been either created or removed by another client.
1044 You can specify this behavior using lookupcache=none. The extra NFS
1045 requests needed if the client does not cache directory entries can ex‐
1046 act a performance penalty. Disabling lookup caching should result in
1047 less of a performance penalty than using noac, and has no effect on how
1048 the NFS client caches the attributes of files.
1049 The sync mount option
1051 The NFS client treats the sync mount option differently than some other
1052 file systems (refer to mount(8) for a description of the generic sync
1053 and async mount options). If neither sync nor async is specified (or
1054 if the async option is specified), the NFS client delays sending appli‐
1055 cation writes to the server until any of these events occur:
1056 Memory pressure forces reclamation of system memory resources.
1058 An application flushes file data explicitly with sync(2),
1060 msync(2), or fsync(3).
1061 An application closes a file with close(2).
1063 The file is locked/unlocked via fcntl(2).
1065 In other words, under normal circumstances, data written by an applica‐
1067 tion may not immediately appear on the server that hosts the file.
1068 If the sync option is specified on a mount point, any system call that
1070 writes data to files on that mount point causes that data to be flushed
1071 to the server before the system call returns control to user space.
1072 This provides greater data cache coherence among clients, but at a sig‐
1073 nificant performance cost.
1074 Applications can use the O_SYNC open flag to force application writes
1076 to individual files to go to the server immediately without the use of
1077 the sync mount option.
1078 Using file locks with NFS
1080 The Network Lock Manager protocol is a separate sideband protocol used
1081 to manage file locks in NFS version 3. To support lock recovery after
1082 a client or server reboot, a second sideband protocol -- known as the
1083 Network Status Manager protocol -- is also required. In NFS version 4,
1084 file locking is supported directly in the main NFS protocol, and the
1085 NLM and NSM sideband protocols are not used.
1086 In most cases, NLM and NSM services are started automatically, and no
1088 extra configuration is required. Configure all NFS clients with fully-
1089 qualified domain names to ensure that NFS servers can find clients to
1090 notify them of server reboots.
1091 NLM supports advisory file locks only. To lock NFS files, use fcntl(2)
1093 with the F_GETLK and F_SETLK commands. The NFS client converts file
1094 locks obtained via flock(2) to advisory locks.
1095 When mounting servers that do not support the NLM protocol, or when
1097 mounting an NFS server through a firewall that blocks the NLM service
1098 port, specify the nolock mount option. NLM locking must be disabled
1099 with the nolock option when using NFS to mount /var because /var con‐
1100 tains files used by the NLM implementation on Linux.
1101 Specifying the nolock option may also be advised to improve the perfor‐
1103 mance of a proprietary application which runs on a single client and
1104 uses file locks extensively.
1105 NFS version 4 caching features
1107 The data and metadata caching behavior of NFS version 4 clients is sim‐
1108 ilar to that of earlier versions. However, NFS version 4 adds two fea‐
1109 tures that improve cache behavior: change attributes and file delega‐
1110 tion.
1111 The change attribute is a new part of NFS file and directory metadata
1113 which tracks data changes. It replaces the use of a file's modifica‐
1114 tion and change time stamps as a way for clients to validate the con‐
1115 tent of their caches. Change attributes are independent of the time
1116 stamp resolution on either the server or client, however.
1117 A file delegation is a contract between an NFS version 4 client and
1119 server that allows the client to treat a file temporarily as if no
1120 other client is accessing it. The server promises to notify the client
1121 (via a callback request) if another client attempts to access that
1122 file. Once a file has been delegated to a client, the client can cache
1123 that file's data and metadata aggressively without contacting the
1124 server.
1125 File delegations come in two flavors: read and write. A read delega‐
1127 tion means that the server notifies the client about any other clients
1128 that want to write to the file. A write delegation means that the
1129 client gets notified about either read or write accessors.
1130 Servers grant file delegations when a file is opened, and can recall
1132 delegations at any time when another client wants access to the file
1133 that conflicts with any delegations already granted. Delegations on
1134 directories are not supported.
1135 In order to support delegation callback, the server checks the network
1137 return path to the client during the client's initial contact with the
1138 server. If contact with the client cannot be established, the server
1139 simply does not grant any delegations to that client.
1140
1142 NFS servers control access to file data, but they depend on their RPC
1143 implementation to provide authentication of NFS requests. Traditional
1144 NFS access control mimics the standard mode bit access control provided
1145 in local file systems. Traditional RPC authentication uses a number to
1146 represent each user (usually the user's own uid), a number to represent
1147 the user's group (the user's gid), and a set of up to 16 auxiliary
1148 group numbers to represent other groups of which the user may be a mem‐
1149 ber.
1150 Typically, file data and user ID values appear unencrypted (i.e. "in
1152 the clear") on the network. Moreover, NFS versions 2 and 3 use sepa‐
1153 rate sideband protocols for mounting, locking and unlocking files, and
1154 reporting system status of clients and servers. These auxiliary proto‐
1155 cols use no authentication.
1156 In addition to combining these sideband protocols with the main NFS
1158 protocol, NFS version 4 introduces more advanced forms of access con‐
1159 trol, authentication, and in-transit data protection. The NFS version
1160 4 specification mandates support for strong authentication and security
1161 flavors that provide per-RPC integrity checking and encryption. Be‐
1162 cause NFS version 4 combines the function of the sideband protocols
1163 into the main NFS protocol, the new security features apply to all NFS
1164 version 4 operations including mounting, file locking, and so on.
1165 RPCGSS authentication can also be used with NFS versions 2 and 3, but
1166 it does not protect their sideband protocols.
1167 The sec mount option specifies the security flavor used for operations
1169 on behalf of users on that NFS mount point. Specifying sec=krb5 pro‐
1170 vides cryptographic proof of a user's identity in each RPC request.
1171 This provides strong verification of the identity of users accessing
1172 data on the server. Note that additional configuration besides adding
1173 this mount option is required in order to enable Kerberos security.
1174 Refer to the rpc.gssd(8) man page for details.
1175 Two additional flavors of Kerberos security are supported: krb5i and
1177 krb5p. The krb5i security flavor provides a cryptographically strong
1178 guarantee that the data in each RPC request has not been tampered with.
1179 The krb5p security flavor encrypts every RPC request to prevent data
1180 exposure during network transit; however, expect some performance im‐
1181 pact when using integrity checking or encryption. Similar support for
1182 other forms of cryptographic security is also available.
1183 NFS version 4 filesystem crossing
1185 The NFS version 4 protocol allows a client to renegotiate the security
1186 flavor when the client crosses into a new filesystem on the server.
1187 The newly negotiated flavor effects only accesses of the new filesys‐
1188 tem.
1189 Such negotiation typically occurs when a client crosses from a server's
1191 pseudo-fs into one of the server's exported physical filesystems, which
1192 often have more restrictive security settings than the pseudo-fs.
1193 NFS version 4 Leases
1195 In NFS version 4, a lease is a period during which a server irrevocably
1196 grants a client file locks. Once the lease expires, the server may re‐
1197 voke those locks. Clients periodically renew their leases to prevent
1198 lock revocation.
1199 After an NFS version 4 server reboots, each client tells the server
1201 about existing file open and lock state under its lease before opera‐
1202 tion can continue. If a client reboots, the server frees all open and
1203 lock state associated with that client's lease.
1204 When establishing a lease, therefore, a client must identify itself to
1206 a server. Each client presents an arbitrary string to distinguish it‐
1207 self from other clients. The client administrator can supplement the
1208 default identity string using the nfs4.nfs4_unique_id module parameter
1209 to avoid collisions with other client identity strings.
1210 A client also uses a unique security flavor and principal when it es‐
1212 tablishes its lease. If two clients present the same identity string,
1213 a server can use client principals to distinguish between them, thus
1214 securely preventing one client from interfering with the other's lease.
1215 The Linux NFS client establishes one lease on each NFS version 4
1217 server. Lease management operations, such as lease renewal, are not
1218 done on behalf of a particular file, lock, user, or mount point, but on
1219 behalf of the client that owns that lease. A client uses a consistent
1220 identity string, security flavor, and principal across client reboots
1221 to ensure that the server can promptly reap expired lease state.
1222 When Kerberos is configured on a Linux NFS client (i.e., there is a
1224 /etc/krb5.keytab on that client), the client attempts to use a Kerberos
1225 security flavor for its lease management operations. Kerberos provides
1226 secure authentication of each client. By default, the client uses the
1227 host/ or nfs/ service principal in its /etc/krb5.keytab for this pur‐
1228 pose, as described in rpc.gssd(8).
1229 If the client has Kerberos configured, but the server does not, or if
1231 the client does not have a keytab or the requisite service principals,
1232 the client uses AUTH_SYS and UID 0 for lease management.
1233 Using non-privileged source ports
1235 NFS clients usually communicate with NFS servers via network sockets.
1236 Each end of a socket is assigned a port value, which is simply a number
1237 between 1 and 65535 that distinguishes socket endpoints at the same IP
1238 address. A socket is uniquely defined by a tuple that includes the
1239 transport protocol (TCP or UDP) and the port values and IP addresses of
1240 both endpoints.
1241 The NFS client can choose any source port value for its sockets, but
1243 usually chooses a privileged port. A privileged port is a port value
1244 less than 1024. Only a process with root privileges may create a
1245 socket with a privileged source port.
1246 The exact range of privileged source ports that can be chosen is set by
1248 a pair of sysctls to avoid choosing a well-known port, such as the port
1249 used by ssh. This means the number of source ports available for the
1250 NFS client, and therefore the number of socket connections that can be
1251 used at the same time, is practically limited to only a few hundred.
1252 As described above, the traditional default NFS authentication scheme,
1254 known as AUTH_SYS, relies on sending local UID and GID numbers to iden‐
1255 tify users making NFS requests. An NFS server assumes that if a con‐
1256 nection comes from a privileged port, the UID and GID numbers in the
1257 NFS requests on this connection have been verified by the client's ker‐
1258 nel or some other local authority. This is an easy system to spoof,
1259 but on a trusted physical network between trusted hosts, it is entirely
1260 adequate.
1261 Roughly speaking, one socket is used for each NFS mount point. If a
1263 client could use non-privileged source ports as well, the number of
1264 sockets allowed, and thus the maximum number of concurrent mount
1265 points, would be much larger.
1266 Using non-privileged source ports may compromise server security some‐
1268 what, since any user on AUTH_SYS mount points can now pretend to be any
1269 other when making NFS requests. Thus NFS servers do not support this
1270 by default. They explicitly allow it usually via an export option.
1271 To retain good security while allowing as many mount points as possi‐
1273 ble, it is best to allow non-privileged client connections only if the
1274 server and client both require strong authentication, such as Kerberos.
1275 Mounting through a firewall
1277 A firewall may reside between an NFS client and server, or the client
1278 or server may block some of its own ports via IP filter rules. It is
1279 still possible to mount an NFS server through a firewall, though some
1280 of the mount(8) command's automatic service endpoint discovery mecha‐
1281 nisms may not work; this requires you to provide specific endpoint de‐
1282 tails via NFS mount options.
1283 NFS servers normally run a portmapper or rpcbind daemon to advertise
1285 their service endpoints to clients. Clients use the rpcbind daemon to
1286 determine:
1287 What network port each RPC-based service is using
1289 What transport protocols each RPC-based service supports
1291 The rpcbind daemon uses a well-known port number (111) to help clients
1293 find a service endpoint. Although NFS often uses a standard port num‐
1294 ber (2049), auxiliary services such as the NLM service can choose any
1295 unused port number at random.
1296 Common firewall configurations block the well-known rpcbind port. In
1298 the absense of an rpcbind service, the server administrator fixes the
1299 port number of NFS-related services so that the firewall can allow ac‐
1300 cess to specific NFS service ports. Client administrators then specify
1301 the port number for the mountd service via the mount(8) command's
1302 mountport option. It may also be necessary to enforce the use of TCP
1303 or UDP if the firewall blocks one of those transports.
1304 NFS Access Control Lists
1306 Solaris allows NFS version 3 clients direct access to POSIX Access Con‐
1307 trol Lists stored in its local file systems. This proprietary sideband
1308 protocol, known as NFSACL, provides richer access control than mode
1309 bits. Linux implements this protocol for compatibility with the So‐
1310 laris NFS implementation. The NFSACL protocol never became a standard
1311 part of the NFS version 3 specification, however.
1312 The NFS version 4 specification mandates a new version of Access Con‐
1314 trol Lists that are semantically richer than POSIX ACLs. NFS version 4
1315 ACLs are not fully compatible with POSIX ACLs; as such, some transla‐
1316 tion between the two is required in an environment that mixes POSIX
1317 ACLs and NFS version 4.
1318
1320 Generic mount options such as rw and sync can be modified on NFS mount
1321 points using the remount option. See mount(8) for more information on
1322 generic mount options.
1323 With few exceptions, NFS-specific options are not able to be modified
1325 during a remount. The underlying transport or NFS version cannot be
1326 changed by a remount, for example.
1327 Performing a remount on an NFS file system mounted with the noac option
1329 may have unintended consequences. The noac option is a combination of
1330 the generic option sync, and the NFS-specific option actimeo=0.
1331 Unmounting after a remount
1333 For mount points that use NFS versions 2 or 3, the NFS umount subcom‐
1334 mand depends on knowing the original set of mount options used to per‐
1335 form the MNT operation. These options are stored on disk by the NFS
1336 mount subcommand, and can be erased by a remount.
1337 To ensure that the saved mount options are not erased during a remount,
1339 specify either the local mount directory, or the server hostname and
1340 export pathname, but not both, during a remount. For example,
1341 mount -o remount,ro /mnt
1343 merges the mount option ro with the mount options already saved on disk
1345 for the NFS server mounted at /mnt.
1346
1348 /etc/fstab file system table
1349 /etc/nfsmount.conf
1351 Configuration file for NFS mounts
1352
1354 Before 2.4.7, the Linux NFS client did not support NFS over TCP.
1355 Before 2.4.20, the Linux NFS client used a heuristic to determine
1357 whether cached file data was still valid rather than using the standard
1358 close-to-open cache coherency method described above.
1359 Starting with 2.4.22, the Linux NFS client employs a Van Jacobsen-based
1361 RTT estimator to determine retransmit timeout values when using NFS
1362 over UDP.
1363 Before 2.6.0, the Linux NFS client did not support NFS version 4.
1365 Before 2.6.8, the Linux NFS client used only synchronous reads and
1367 writes when the rsize and wsize settings were smaller than the system's
1368 page size.
1369 The Linux client's support for protocol versions depend on whether the
1371 kernel was built with options CONFIG_NFS_V2, CONFIG_NFS_V3, CON‐
1372 FIG_NFS_V4, CONFIG_NFS_V4_1, and CONFIG_NFS_V4_2.
1373
1375 fstab(5), mount(8), umount(8), mount.nfs(5), umount.nfs(5), exports(5),
1376 nfsmount.conf(5), netconfig(5), ipv6(7), nfsd(8), sm-notify(8),
1377 rpc.statd(8), rpc.idmapd(8), rpc.gssd(8), rpc.svcgssd(8), kerberos(1)
1378 RFC 768 for the UDP specification.
1380 RFC 793 for the TCP specification.
1381 RFC 1813 for the NFS version 3 specification.
1382 RFC 1832 for the XDR specification.
1383 RFC 1833 for the RPC bind specification.
1384 RFC 2203 for the RPCSEC GSS API protocol specification.
1385 RFC 7530 for the NFS version 4.0 specification.
1386 RFC 5661 for the NFS version 4.1 specification.
1387 RFC 7862 for the NFS version 4.2 specification.
1388 9 October 2012 NFS(5)