93bd642dc685f47dda84d5a0e72f0213d5f55a3a
[nfs-utils.git] / utils / mount / nfs.man
1 .\"@(#)nfs.5"
2 .TH NFS 5 "2 November 2007"
3 .SH NAME
4 nfs \- fstab format and options for the
5 .B nfs
6 and
7 .B nfs4
8 file systems
9 .SH SYNOPSIS
10 .I /etc/fstab
11 .SH DESCRIPTION
12 NFS is an Internet Standard protocol
13 created by Sun Microsystems in 1984. NFS was developed
14 to allow file sharing between systems residing
15 on a local area network.
16 The Linux NFS client supports three versions
17 of the NFS protocol:
18 NFS version 2 [RFC1094],
19 NFS version 3 [RFC1813],
20 and NFS version 4 [RFC3530].
21 .P
22 The
23 .BR mount (8)
24 command attaches a file system to the system's
25 name space hierarchy at a given mount point.
26 The
27 .I /etc/fstab
28 file describes how
29 .BR mount (8)
30 should assemble a system's file name hierarchy
31 from various independent file systems
32 (including file systems exported by NFS servers).
33 Each line in the
34 .I /etc/fstab
35 file describes a single file system, its mount point,
36 and a set of default mount options for that mount point.
37 .P
38 For NFS file system mounts, a line in the
39 .I /etc/fstab
40 file specifies the server name,
41 the path name of the exported server directory to mount,
42 the local directory that is the mount point,
43 the type of file system that is being mounted,
44 and a list of mount options that control
45 the way the filesystem is mounted and
46 how the NFS client behaves when accessing
47 files on this mount point.
48 The fifth and sixth fields on each line are not used
49 by NFS, thus conventionally each contain the digit zero. For example:
50 .P
51 .SP
52 .NF
53 .TA 2.5i +0.75i +0.75i +1.0i
54         server:path     /mountpoint     fstype  option,option,...       0 0
55 .FI
56 .P
57 The server's hostname and export pathname
58 are separated by a colon, while
59 the mount options are separated by commas. The remaining fields
60 are separated by blanks or tabs.
61 .P
62 The server's hostname can be an unqualified hostname,
63 a fully qualified domain name,
64 a dotted quad IPv4 address, or
65 an IPv6 address enclosed in square brackets.
66 Link-local and site-local IPv6 addresses must be accompanied by an
67 interface identifier.
68 See
69 .BR ipv6 (7)
70 for details on specifying raw IPv6 addresses.
71 .P
72 The
73 .I fstype
74 field contains either "nfs" (for version 2 or version 3 NFS mounts)
75 or "nfs4" (for NFS version 4 mounts).
76 The
77 .B nfs
78 and
79 .B nfs4
80 file system types share similar mount options,
81 which are described below.
82 .SH "MOUNT OPTIONS"
83 Refer to
84 .BR mount (8)
85 for a description of generic mount options
86 available for all file systems. If you do not need to
87 specify any mount options, use the generic option
88 .B defaults
89 in
90 .IR /etc/fstab .
91 .DT
92 .SS "Valid options for either the nfs or nfs4 file system type"
93 These options are valid to use when mounting either
94 .B nfs
95 or
96 .B nfs4
97 file system types.
98 They imply the same behavior
99 and have the same default for both file system types.
100 .TP 1.5i
101 .BR soft " / " hard
102 Determines the recovery behavior of the NFS client
103 after an NFS request times out.
104 If neither option is specified (or if the
105 .B hard
106 option is specified), NFS requests are retried indefinitely.
107 If the
108 .B soft
109 option is specified, then the NFS client fails an NFS request
110 after
111 .B retrans
112 retransmissions have been sent,
113 causing the NFS client to return an error
114 to the calling application.
115 .IP
116 .I NB:
117 A so-called "soft" timeout can cause
118 silent data corruption in certain cases. As such, use the
119 .B soft
120 option only when client responsiveness
121 is more important than data integrity.
122 Using NFS over TCP or increasing the value of the
123 .B retrans
124 option may mitigate some of the risks of using the
125 .B soft
126 option.
127 .TP 1.5i
128 .BI timeo= n
129 The time (in tenths of a second) the NFS client waits for a
130 response before it retries an NFS request. If this
131 option is not specified, requests are retried every
132 60 seconds for NFS over TCP.
133 The NFS client does not perform any kind of timeout backoff
134 for NFS over TCP.
135 .IP
136 However, for NFS over UDP, the client uses an adaptive
137 algorithm to estimate an appropriate timeout value for frequently used
138 request types (such as READ and WRITE requests), but uses the
139 .B timeo
140 setting for infrequently used request types (such as FSINFO requests).
141 If the
142 .B timeo
143 option is not specified,
144 infrequently used request types are retried after 1.1 seconds.
145 After each retransmission, the NFS client doubles the timeout for
146 that request,
147 up to a maximum timeout length of 60 seconds.
148 .TP 1.5i
149 .BI retrans= n
150 The number of times the NFS client retries a request before
151 it attempts further recovery action. If the
152 .B retrans
153 option is not specified, the NFS client tries each request
154 three times.
155 .IP
156 The NFS client generates a "server not responding" message
157 after
158 .B retrans
159 retries, then attempts further recovery (depending on whether the
160 .B hard
161 mount option is in effect).
162 .TP 1.5i
163 .BI rsize= n
164 The maximum number of bytes in each network READ request
165 that the NFS client can receive when reading data from a file
166 on an NFS server.
167 The actual data payload size of each NFS READ request is equal to
168 or smaller than the
169 .B rsize
170 setting. The largest read payload supported by the Linux NFS client
171 is 1,048,576 bytes (one megabyte).
172 .IP
173 The
174 .B rsize
175 value is a positive integral multiple of 1024.
176 Specified
177 .B rsize
178 values lower than 1024 are replaced with 4096; values larger than
179 1048576 are replaced with 1048576. If a specified value is within the supported
180 range but not a multiple of 1024, it is rounded down to the nearest
181 multiple of 1024.
182 .IP
183 If an
184 .B rsize
185 value is not specified, or if the specified
186 .B rsize
187 value is larger than the maximum that either client or server can support,
188 the client and server negotiate the largest
189 .B rsize
190 value that they can both support.
191 .IP
192 The
193 .B rsize
194 mount option as specified on the
195 .BR mount (8)
196 command line appears in the
197 .I /etc/mtab
198 file. However, the effective
199 .B rsize
200 value negotiated by the client and server is reported in the
201 .I /proc/mounts
202 file.
203 .TP 1.5i
204 .BI wsize= n
205 The maximum number of bytes per network WRITE request
206 that the NFS client can send when writing data to a file
207 on an NFS server. The actual data payload size of each
208 NFS WRITE request is equal to
209 or smaller than the
210 .B wsize
211 setting. The largest write payload supported by the Linux NFS client
212 is 1,048,576 bytes (one megabyte).
213 .IP
214 Similar to
215 .B rsize
216 , the
217 .B wsize
218 value is a positive integral multiple of 1024.
219 Specified
220 .B wsize
221 values lower than 1024 are replaced with 4096; values larger than
222 1048576 are replaced with 1048576. If a specified value is within the supported
223 range but not a multiple of 1024, it is rounded down to the nearest
224 multiple of 1024.
225 .IP
226 If a
227 .B wsize
228 value is not specified, or if the specified
229 .B wsize
230 value is larger than the maximum that either client or server can support,
231 the client and server negotiate the largest
232 .B wsize
233 value that they can both support.
234 .IP
235 The
236 .B wsize
237 mount option as specified on the
238 .BR mount (8)
239 command line appears in the
240 .I /etc/mtab
241 file. However, the effective
242 .B wsize
243 value negotiated by the client and server is reported in the
244 .I /proc/mounts
245 file.
246 .TP 1.5i
247 .BR ac " / " noac
248 Selects whether the client may cache file attributes. If neither
249 option is specified (or if
250 .B ac
251 is specified), the client caches file
252 attributes.
253 .IP
254 To improve performance, NFS clients cache file
255 attributes. Every few seconds, an NFS client checks the server's version of each
256 file's attributes for updates.  Changes that occur on the server in
257 those small intervals remain undetected until the client checks the
258 server again. The
259 .B noac
260 option prevents clients from caching file
261 attributes so that applications can more quickly detect file changes
262 on the server.
263 .IP
264 In addition to preventing the client from caching file attributes,
265 the
266 .B noac
267 option forces application writes to become synchronous so
268 that local changes to a file become visible on the server
269 immediately.  That way, other clients can quickly detect recent
270 writes when they check the file's attributes.
271 .IP
272 Using the
273 .B noac
274 option provides greater cache coherence among NFS clients
275 accessing the same files,
276 but it extracts a significant performance penalty.
277 As such, judicious use of file locking is encouraged instead.
278 The DATA AND METADATA COHERENCE section contains a detailed discussion
279 of these trade-offs.
280 .TP 1.5i
281 .BI acregmin= n
282 The minimum time (in seconds) that the NFS client caches
283 attributes of a regular file before it requests
284 fresh attribute information from a server.
285 If this option is not specified, the NFS client uses
286 a 3-second minimum.
287 .TP 1.5i
288 .BI acregmax= n
289 The maximum time (in seconds) that the NFS client caches
290 attributes of a regular file before it requests
291 fresh attribute information from a server.
292 If this option is not specified, the NFS client uses
293 a 60-second maximum.
294 .TP 1.5i
295 .BI acdirmin= n
296 The minimum time (in seconds) that the NFS client caches
297 attributes of a directory before it requests
298 fresh attribute information from a server.
299 If this option is not specified, the NFS client uses
300 a 30-second minimum.
301 .TP 1.5i
302 .BI acdirmax= n
303 The maximum time (in seconds) that the NFS client caches
304 attributes of a directory before it requests
305 fresh attribute information from a server.
306 If this option is not specified, the NFS client uses
307 a 60-second maximum.
308 .TP 1.5i
309 .BI actimeo= n
310 Using
311 .B actimeo
312 sets all of
313 .BR acregmin ,
314 .BR acregmax ,
315 .BR acdirmin ,
316 and
317 .B acdirmax
318 to the same value.
319 If this option is not specified, the NFS client uses
320 the defaults for each of these options listed above.
321 .TP 1.5i
322 .BR bg " / " fg
323 Determines how the
324 .BR mount (8)
325 command behaves if an attempt to mount an export fails.
326 The
327 .B fg
328 option causes
329 .BR mount (8)
330 to exit with an error status if any part of the mount request
331 times out or fails outright.
332 This is called a "foreground" mount,
333 and is the default behavior if neither the
334 .B fg
335 nor
336 .B bg
337 mount option is specified.
338 .IP
339 If the
340 .B bg
341 option is specified, a timeout or failure causes the
342 .BR mount (8)
343 command to fork a child which continues to attempt
344 to mount the export.
345 The parent immediately returns with a zero exit code.
346 This is known as a "background" mount.
347 .IP
348 If the local mount point directory is missing, the
349 .BR mount (8)
350 command acts as if the mount request timed out.
351 This permits nested NFS mounts specified in
352 .I /etc/fstab
353 to proceed in any order during system initialization,
354 even if some NFS servers are not yet available.
355 Alternatively these issues can be addressed
356 using an automounter (refer to
357 .BR automount (8)
358 for details).
359 .TP 1.5i
360 .BI retry= n
361 The number of minutes that the
362 .BR mount (8)
363 command retries an NFS mount operation
364 in the foreground or background before giving up.
365 If this option is not specified, the default value for foreground mounts
366 is 2 minutes, and the default value for background mounts is 10000 minutes (80 minutes shy of one week).
367 .TP 1.5i
368 .BI sec= mode
369 The RPCGSS security flavor to use for accessing files on this mount point.
370 If the
371 .B sec
372 option is not specified, or if
373 .B sec=sys
374 is specified, the NFS client uses the AUTH_SYS security flavor
375 for all NFS requests on this mount point.
376 Valid security flavors are
377 .BR none ,
378 .BR sys ,
379 .BR krb5 ,
380 .BR krb5i ,
381 .BR krb5p ,
382 .BR lkey ,
383 .BR lkeyi ,
384 .BR lkeyp ,
385 .BR spkm ,
386 .BR spkmi ,
387 and
388 .BR spkmp .
389 Refer to the SECURITY CONSIDERATIONS section for details.
390 .TP 1.5i
391 .BR sharecache " / " nosharecache
392 Determines how the client's data cache and attribute cache are shared
393 when mounting the same export more than once concurrently.  Using the
394 same cache reduces memory requirements on the client and presents
395 identical file contents to applications when the same remote file is
396 accessed via different mount points.
397 .IP
398 If neither option is specified, or if the
399 .B sharecache
400 option is
401 specified, then a single cache is used for all mount points that
402 access the same export.  If the
403 .B nosharecache
404 option is specified,
405 then that mount point gets a unique cache.  Note that when data and
406 attribute caches are shared, the mount options from the first mount
407 point take effect for subsequent concurrent mounts of the same export.
408 .IP
409 As of kernel 2.6.18, the behavior specified by
410 .B nosharecache
411 is legacy caching behavior. This
412 is considered a data risk since multiple cached copies
413 of the same file on the same client can become out of sync
414 following a local update of one of the copies.
415 .TP 1.5i
416 .BR resvport " / " noresvport
417 Specifies whether the NFS client should use a privileged source port
418 when communicating with an NFS server for this mount point.
419 If this option is not specified, or the
420 .B resvport
421 option is specified, the NFS client uses a privileged source port.
422 If the
423 .B noresvport
424 option is specified, the NFS client uses a non-privileged source port.
425 This option is supported in kernels 2.6.28 and later.
426 .IP
427 Using non-privileged source ports helps increase the maximum number of
428 NFS mount points allowed on a client, but NFS servers must be configured
429 to allow clients to connect via non-privileged source ports.
430 .IP
431 Refer to the SECURITY CONSIDERATIONS section for important details.
432 .TP 1.5i
433 .BI lookupcache= mode
434 Specifies how the kernel manages its cache of directory entries
435 for a given mount point.
436 .I mode
437 can be one of
438 .BR all ,
439 .BR none ,
440 .BR pos ,
441 or
442 .BR positive .
443 This option is supported in kernels 2.6.28 and later.
444 .IP
445 The Linux NFS client caches the result of all NFS LOOKUP requests.
446 If the requested directory entry exists on the server,
447 the result is referred to as
448 .IR positive .
449 If the requested directory entry does not exist on the server,
450 the result is referred to as
451 .IR negative .
452 .IP
453 If this option is not specified, or if
454 .B all
455 is specified, the client assumes both types of directory cache entries
456 are valid until their parent directory's cached attributes expire.
457 .IP
458 If
459 .BR pos " or " positive
460 is specified, the client assumes positive entries are valid
461 until their parent directory's cached attributes expire, but
462 always revalidates negative entires before an application
463 can use them.
464 .IP
465 If
466 .B none
467 is specified,
468 the client revalidates both types of directory cache entries
469 before an application can use them.
470 This permits quick detection of files that were created or removed
471 by other clients, but can impact application and server performance.
472 .IP
473 The DATA AND METADATA COHERENCE section contains a
474 detailed discussion of these trade-offs.
475 .SS "Valid options for the nfs file system type"
476 Use these options, along with the options in the above subsection,
477 for mounting the
478 .B nfs
479 file system type.
480 .TP 1.5i
481 .BI proto= netid
482 The transport protocol name and protocol family the NFS client uses
483 to transmit requests to the NFS server for this mount point.
484 If an NFS server has both an IPv4 and an IPv6 address, using a specific
485 netid will force the use of IPv4 or IPv6 networking to communicate
486 with that server.
487 .IP
488 If support for TI-RPC is built into the
489 .B mount.nfs
490 command,
491 .I netid
492 is a valid netid listed in
493 .IR /etc/netconfig .
494 Otherwise,
495 .I netid
496 is one of "tcp," "udp," or "rdma," and only IPv4 may be used.
497 .IP
498 Each transport protocol uses different default
499 .B retrans
500 and
501 .B timeo
502 settings.
503 Refer to the description of these two mount options for details.
504 .IP
505 In addition to controlling how the NFS client transmits requests to
506 the server, this mount option also controls how the
507 .BR mount (8)
508 command communicates with the server's rpcbind and mountd services.
509 Specifying a netid that uses TCP forces all traffic from the
510 .BR mount (8)
511 command and the NFS client to use TCP.
512 Specifying a netid that uses UDP forces all traffic types to use UDP.
513 .IP
514 If the
515 .B proto
516 mount option is not specified, the
517 .BR mount (8)
518 command discovers which protocols the server supports
519 and chooses an appropriate transport for each service.
520 Refer to the TRANSPORT METHODS section for more details.
521 .TP 1.5i
522 .B udp
523 The
524 .B udp
525 option is an alternative to specifying
526 .BR proto=udp.
527 It is included for compatibility with other operating systems.
528 .TP 1.5i
529 .B tcp
530 The
531 .B tcp
532 option is an alternative to specifying
533 .BR proto=tcp.
534 It is included for compatibility with other operating systems.
535 .TP 1.5i
536 .BI port= n
537 The numeric value of the server's NFS service port.
538 If the server's NFS service is not available on the specified port,
539 the mount request fails.
540 .IP
541 If this option is not specified, or if the specified port value is 0,
542 then the NFS client uses the NFS service port number
543 advertised by the server's rpcbind service.
544 The mount request fails if the server's rpcbind service is not available,
545 the server's NFS service is not registered with its rpcbind service,
546 or the server's NFS service is not available on the advertised port.
547 .TP 1.5i
548 .BI mountport= n
549 The numeric value of the server's mountd port.
550 If the server's mountd service is not available on the specified port,
551 the mount request fails.
552 .IP
553 If this option is not specified,
554 or if the specified port value is 0, then the
555 .BR mount (8)
556 command uses the mountd service port number
557 advertised by the server's rpcbind service.
558 The mount request fails if the server's rpcbind service is not available,
559 the server's mountd service is not registered with its rpcbind service,
560 or the server's mountd service is not available on the advertised port.
561 .IP
562 This option can be used when mounting an NFS server
563 through a firewall that blocks the rpcbind protocol.
564 .TP 1.5i
565 .BI mountproto= netid
566 The transport protocol name and protocol family the NFS client uses
567 to transmit requests to the NFS server's mountd service when performing
568 this mount request, and when later unmounting this mount point.
569 .IP
570 If support for TI-RPC is built into the
571 .B mount.nfs
572 command,
573 .I netid
574 is a valid netid listed in
575 .IR /etc/netconfig .
576 Otherwise,
577 .I netid
578 is one of "tcp" or "udp," and only IPv4 may be used.
579 .IP
580 This option can be used when mounting an NFS server
581 through a firewall that blocks a particular transport.
582 When used in combination with the
583 .B proto
584 option, different transports for mountd requests and NFS requests
585 can be specified.
586 If the server's mountd service is not available via the specified
587 transport, the mount request fails.
588 .IP
589 Refer to the TRANSPORT METHODS section for more on how the
590 .B mountproto
591 mount option interacts with the
592 .B proto
593 mount option.
594 .TP 1.5i
595 .BI mounthost= name
596 The hostname of the host running mountd.
597 If this option is not specified, the
598 .BR mount (8)
599 command assumes that the mountd service runs
600 on the same host as the NFS service.
601 .TP 1.5i
602 .BI mountvers= n
603 The RPC version number used to contact the server's mountd.
604 If this option is not specified, the client uses a version number
605 appropriate to the requested NFS version.
606 This option is useful when multiple NFS services
607 are running on the same remote server host.
608 .TP 1.5i
609 .BI namlen= n
610 The maximum length of a pathname component on this mount.
611 If this option is not specified, the maximum length is negotiated
612 with the server. In most cases, this maximum length is 255 characters.
613 .IP
614 Some early versions of NFS did not support this negotiation.
615 Using this option ensures that
616 .BR pathconf (3)
617 reports the proper maximum component length to applications
618 in such cases.
619 .TP 1.5i
620 .BI nfsvers= n
621 The NFS protocol version number used to contact the server's NFS service.
622 The Linux client supports version 2 and version 3 of the NFS protocol
623 when using the file system type
624 .BR nfs .
625 If the server does not support the requested version,
626 the mount request fails.
627 If this option is not specified, the client attempts to use version 3,
628 but negotiates the NFS version with the server if version 3 support
629 is not available.
630 .TP 1.5i
631 .BI vers= n
632 This option is an alternative to the
633 .B nfsvers
634 option.
635 It is included for compatibility with other operating systems.
636 .TP 1.5i
637 .BR lock " / " nolock
638 Selects whether to use the NLM sideband protocol to lock files on the server.
639 If neither option is specified (or if
640 .B lock
641 is specified), NLM locking is used for this mount point.
642 When using the
643 .B nolock
644 option, applications can lock files,
645 but such locks provide exclusion only against other applications
646 running on the same client.
647 Remote applications are not affected by these locks.
648 .IP
649 NLM locking must be disabled with the
650 .B nolock
651 option when using NFS to mount
652 .I /var
653 because
654 .I /var
655 contains files used by the NLM implementation on Linux.
656 Using the
657 .B nolock
658 option is also required when mounting exports on NFS servers
659 that do not support the NLM protocol.
660 .TP 1.5i
661 .BR intr " / " nointr
662 Selects whether to allow signals to interrupt file operations
663 on this mount point. If neither option
664 is specified (or if
665 .B nointr
666 is specified),
667 signals do not interrupt NFS file operations. If
668 .B intr
669 is specified, system calls return EINTR if an in-progress NFS operation is interrupted by
670 a signal.
671 .IP
672 Using the
673 .B intr
674 option is preferred to using the
675 .B soft
676 option because it is significantly less likely to result in data corruption.
677 .IP
678 The
679 .BR intr " / " nointr
680 mount option is deprecated after kernel 2.6.25.
681 Only SIGKILL can interrupt a pending NFS operation on these kernels,
682 and if specified, this mount option is ignored to provide backwards
683 compatibility with older kernels.
684 .TP 1.5i
685 .BR cto " / " nocto
686 Selects whether to use close-to-open cache coherence semantics.
687 If neither option is specified (or if
688 .B cto
689 is specified), the client uses close-to-open
690 cache coherence semantics. If the
691 .B nocto
692 option is specified, the client uses a non-standard heuristic to determine when
693 files on the server have changed.
694 .IP
695 Using the
696 .B nocto
697 option may improve performance for read-only mounts,
698 but should be used only if the data on the server changes only occasionally.
699 The DATA AND METADATA COHERENCE section discusses the behavior
700 of this option in more detail.
701 .TP 1.5i
702 .BR acl " / " noacl
703 Selects whether to use the NFSACL sideband protocol on this mount point.
704 The NFSACL sideband protocol is a proprietary protocol
705 implemented in Solaris that manages Access Control Lists. NFSACL was never
706 made a standard part of the NFS protocol specification.
707 .IP
708 If neither
709 .B acl
710 nor
711 .B noacl
712 option is specified,
713 the NFS client negotiates with the server
714 to see if the NFSACL protocol is supported,
715 and uses it if the server supports it.
716 Disabling the NFSACL sideband protocol may be necessary
717 if the negotiation causes problems on the client or server.
718 Refer to the SECURITY CONSIDERATIONS section for more details.
719 .TP 1.5i
720 .BR rdirplus " / " nordirplus
721 Selects whether to use NFS version 3 READDIRPLUS requests.
722 If this option is not specified, the NFS client uses READDIRPLUS requests
723 on NFS version 3 mounts to read small directories.
724 Some applications perform better if the client uses only READDIR requests
725 for all directories.
726 .SS "Valid options for the nfs4 file system type"
727 Use these options, along with the options in the first subsection above,
728 for mounting the
729 .B nfs4
730 file system type.
731 .TP 1.5i
732 .BI proto= netid
733 The transport protocol name and protocol family the NFS client uses
734 to transmit requests to the NFS server for this mount point.
735 If an NFS server has both an IPv4 and an IPv6 address, using a specific
736 netid will force the use of IPv4 or IPv6 networking to communicate
737 with that server.
738 .IP
739 If support for TI-RPC is built into the
740 .B mount.nfs
741 command,
742 .I netid
743 is a valid netid listed in
744 .IR /etc/netconfig .
745 Otherwise,
746 .I netid
747 is one of "tcp" or "udp," and only IPv4 may be used.
748 .IP
749 All NFS version 4 servers are required to support TCP,
750 so if this mount option is not specified, the NFS version 4 client
751 uses the TCP protocol.
752 Refer to the TRANSPORT METHODS section for more details.
753 .TP 1.5i
754 .BI port= n
755 The numeric value of the server's NFS service port.
756 If the server's NFS service is not available on the specified port,
757 the mount request fails.
758 .IP
759 If this mount option is not specified,
760 the NFS client uses the standard NFS port number of 2049
761 without first checking the server's rpcbind service.
762 This allows an NFS version 4 client to contact an NFS version 4
763 server through a firewall that may block rpcbind requests.
764 .IP
765 If the specified port value is 0,
766 then the NFS client uses the NFS service port number
767 advertised by the server's rpcbind service.
768 The mount request fails if the server's rpcbind service is not available,
769 the server's NFS service is not registered with its rpcbind service,
770 or the server's NFS service is not available on the advertised port.
771 .TP 1.5i
772 .BR intr " / " nointr
773 Selects whether to allow signals to interrupt file operations
774 on this mount point. If neither option is specified (or if
775 .B intr
776 is specified), system calls return EINTR if an in-progress NFS operation
777 is interrupted by a signal.  If
778 .B nointr
779 is specified, signals do not
780 interrupt NFS operations.
781 .IP
782 Using the
783 .B intr
784 option is preferred to using the
785 .B soft
786 option because it is significantly less likely to result in data corruption.
787 .IP
788 The
789 .BR intr " / " nointr
790 mount option is deprecated after kernel 2.6.25.
791 Only SIGKILL can interrupt a pending NFS operation on these kernels,
792 and if specified, this mount option is ignored to provide backwards
793 compatibility with older kernels.
794 .TP 1.5i
795 .BR cto " / " nocto
796 Selects whether to use close-to-open cache coherence semantics
797 for NFS directories on this mount point.
798 If neither
799 .B cto
800 nor
801 .B nocto
802 is specified,
803 the default is to use close-to-open cache coherence
804 semantics for directories.
805 .IP
806 File data caching behavior is not affected by this option.
807 The DATA AND METADATA COHERENCE section discusses
808 the behavior of this option in more detail.
809 .TP 1.5i
810 .BI clientaddr= n.n.n.n
811 Specifies a single IPv4 address (in dotted-quad form),
812 or a non-link-local IPv6 address,
813 that the NFS client advertises to allow servers
814 to perform NFS version 4 callback requests against
815 files on this mount point. If  the  server is unable to
816 establish callback connections to clients, performance
817 may degrade, or accesses to files may temporarily hang.
818 .IP
819 If this option is not specified, the
820 .BR mount (8)
821 command attempts to discover an appropriate callback address automatically.
822 The automatic discovery process is not perfect, however.
823 In the presence of multiple client network interfaces,
824 special routing policies,
825 or atypical network topologies,
826 the exact address to use for callbacks may be nontrivial to determine.
827 .SH MOUNT CONFIGURATION FILE
828 If the mount command is configured to do so, all of the mount options 
829 described in the previous section can also be configured in the 
830 .I /etc/nfsmount.conf 
831 file. See 
832 .BR nfsmount.conf(5)
833 for details.
834 .SH EXAMPLES
835 To mount an export using NFS version 2,
836 use the
837 .B nfs
838 file system type and specify the
839 .B nfsvers=2
840 mount option.
841 To mount using NFS version 3,
842 use the
843 .B nfs
844 file system type and specify the
845 .B nfsvers=3
846 mount option.
847 To mount using NFS version 4,
848 use the
849 .B nfs4
850 file system type.
851 The
852 .B nfsvers
853 mount option is not supported for the
854 .B nfs4
855 file system type.
856 .P
857 The following example from an
858 .I /etc/fstab
859 file causes the mount command to negotiate
860 reasonable defaults for NFS behavior.
861 .P
862 .NF
863 .TA 2.5i +0.7i +0.7i +.7i
864         server:/export  /mnt    nfs     defaults        0 0
865 .FI
866 .P
867 Here is an example from an /etc/fstab file for an NFS version 2 mount over UDP.
868 .P
869 .NF
870 .TA 2.5i +0.7i +0.7i +.7i
871         server:/export  /mnt    nfs     nfsvers=2,proto=udp     0 0
872 .FI
873 .P
874 Try this example to mount using NFS version 4 over TCP
875 with Kerberos 5 mutual authentication.
876 .P
877 .NF
878 .TA 2.5i +0.7i +0.7i +.7i
879         server:/export  /mnt    nfs4    sec=krb5        0 0
880 .FI
881 .P
882 This example can be used to mount /usr over NFS.
883 .P
884 .NF
885 .TA 2.5i +0.7i +0.7i +.7i
886         server:/export  /usr    nfs     ro,nolock,nocto,actimeo=3600    0 0
887 .FI
888 .P
889 This example shows how to mount an NFS server
890 using a raw IPv6 link-local address.
891 .P
892 .NF
893 .TA 2.5i +0.7i +0.7i +.7i
894         [fe80::215:c5ff:fb3e:e2b1%eth0]:/export /mnt    nfs     defaults        0 0
895 .FI
896 .SH "TRANSPORT METHODS"
897 NFS clients send requests to NFS servers via
898 Remote Procedure Calls, or
899 .IR RPCs .
900 The RPC client discovers remote service endpoints automatically,
901 handles per-request authentication,
902 adjusts request parameters for different byte endianness on client and server,
903 and retransmits requests that may have been lost by the network or server.
904 RPC requests and replies flow over a network transport.
905 .P
906 In most cases, the
907 .BR mount (8)
908 command, NFS client, and NFS server
909 can automatically negotiate proper transport
910 and data transfer size settings for a mount point.
911 In some cases, however, it pays to specify
912 these settings explicitly using mount options.
913 .P
914 Traditionally, NFS clients used the UDP transport exclusively for
915 transmitting requests to servers.  Though its implementation is
916 simple, NFS over UDP has many limitations that prevent smooth
917 operation and good performance in some common deployment
918 environments.  Even an insignificant packet loss rate results in the
919 loss of whole NFS requests; as such, retransmit timeouts are usually
920 in the subsecond range to allow clients to recover quickly from
921 dropped requests, but this can result in extraneous network traffic
922 and server load.
923 .P
924 However, UDP can be quite effective in specialized settings where
925 the networks MTU is large relative to NFSs data transfer size (such
926 as network environments that enable jumbo Ethernet frames).  In such
927 environments, trimming the
928 .B rsize
929 and
930 .B wsize
931 settings so that each
932 NFS read or write request fits in just a few network frames (or even
933 in  a single  frame) is advised.  This reduces the probability that
934 the loss of a single MTU-sized network frame results in the loss of
935 an entire large read or write request.
936 .P
937 TCP is the default transport protocol used for all modern NFS
938 implementations.  It performs well in almost every conceivable
939 network environment and provides excellent guarantees against data
940 corruption caused by network unreliability.  TCP is often a
941 requirement for mounting a server through a network firewall.
942 .P
943 Under normal circumstances, networks drop packets much more
944 frequently than NFS servers drop requests.  As such, an aggressive
945 retransmit timeout  setting for NFS over TCP is unnecessary. Typical
946 timeout settings for NFS over TCP are between one and ten minutes.
947 After  the client exhausts its retransmits (the value of the
948 .B retrans
949 mount option), it assumes a network partition has occurred,
950 and attempts to reconnect to the server on a fresh socket. Since
951 TCP itself makes network data transfer reliable,
952 .B rsize
953 and
954 .B wsize
955 can safely be allowed to default to the largest values supported by
956 both client and server, independent of the network's MTU size.
957 .SS "Using the mountproto mount option"
958 This section applies only to NFS version 2 and version 3 mounts
959 since NFS version 4 does not use a separate protocol for mount
960 requests.
961 .P
962 The Linux NFS client can use a different transport for
963 contacting an NFS server's rpcbind service, its mountd service,
964 its Network Lock Manager (NLM) service, and its NFS service.
965 The exact transports employed by the Linux NFS client for
966 each mount point depends on the settings of the transport
967 mount options, which include
968 .BR proto ,
969 .BR mountproto ,
970 .BR udp ", and " tcp .
971 .P
972 The client sends Network Status Manager (NSM) notifications
973 via UDP no matter what transport options are specified, but
974 listens for server NSM notifications on both UDP and TCP.
975 The NFS Access Control List (NFSACL) protocol shares the same
976 transport as the main NFS service.
977 .P
978 If no transport options are specified, the Linux NFS client
979 uses UDP to contact the server's mountd service, and TCP to
980 contact its NLM and NFS services by default.
981 .P
982 If the server does not support these transports for these services, the
983 .BR mount (8)
984 command attempts to discover what the server supports, and then retries
985 the mount request once using the discovered transports.
986 If the server does not advertise any transport supported by the client
987 or is misconfigured, the mount request fails.
988 If the
989 .B bg
990 option is in effect, the mount command backgrounds itself and continues
991 to attempt the specified mount request.
992 .P
993 When the
994 .B proto
995 option, the
996 .B udp
997 option, or the
998 .B tcp
999 option is specified but the
1000 .B mountproto
1001 option is not, the specified transport is used to contact
1002 both the server's mountd service and for the NLM and NFS services.
1003 .P
1004 If the
1005 .B mountproto
1006 option is specified but none of the
1007 .BR proto ", " udp " or " tcp
1008 options are specified, then the specified transport is used for the
1009 initial mountd request, but the mount command attempts to discover
1010 what the server supports for the NFS protocol, preferring TCP if
1011 both transports are supported.
1012 .P
1013 If both the
1014 .BR mountproto " and " proto
1015 (or
1016 .BR udp " or " tcp )
1017 options are specified, then the transport specified by the
1018 .B mountproto
1019 option is used for the initial mountd request, and the transport
1020 specified by the
1021 .B proto
1022 option (or the
1023 .BR udp " or " tcp " options)"
1024 is used for NFS, no matter what order these options appear.
1025 No automatic service discovery is performed if these options are
1026 specified.
1027 .P
1028 If any of the
1029 .BR proto ", " udp ", " tcp ", "
1030 or
1031 .B mountproto
1032 options are specified more than once on the same mount command line,
1033 then the value of the rightmost instance of each of these options
1034 takes effect.
1035 .SH "DATA AND METADATA COHERENCE"
1036 Some modern cluster file systems provide
1037 perfect cache coherence among their clients.
1038 Perfect cache coherence among disparate NFS clients
1039 is expensive to achieve, especially on wide area networks.
1040 As such, NFS settles for weaker cache coherence that
1041 satisfies the requirements of most file sharing types. Normally,
1042 file sharing is completely sequential:
1043 first client A opens a file, writes something to it, then closes it;
1044 then client B opens the same file, and reads the changes.
1045 .DT
1046 .SS "Close-to-open cache consistency"
1047 When an application opens a file stored on an NFS server,
1048 the NFS client checks that it still exists on the server
1049 and is permitted to the opener by sending a GETATTR or ACCESS request.
1050 When the application closes the file,
1051 the NFS client writes back any pending changes
1052 to the file so that the next opener can view the changes.
1053 This also gives the NFS client an opportunity to report
1054 any server write errors to the application
1055 via the return code from
1056 .BR close (2).
1057 The behavior of checking at open time and flushing at close time
1058 is referred to as close-to-open cache consistency.
1059 .SS "Weak cache consistency"
1060 There are still opportunities for a client's data cache
1061 to contain stale data.
1062 The NFS version 3 protocol introduced "weak cache consistency"
1063 (also known as WCC) which provides a way of efficiently checking
1064 a file's attributes before and after a single request.
1065 This allows a client to help identify changes
1066 that could have been made by other clients.
1067 .P
1068 When a client is using many concurrent operations
1069 that update the same file at the same time
1070 (for example, during asynchronous write behind),
1071 it is still difficult to tell whether it was
1072 that client's updates or some other client's updates
1073 that altered the file.
1074 .SS "Attribute caching"
1075 Use the
1076 .B noac
1077 mount option to achieve attribute cache coherence
1078 among multiple clients.
1079 Almost every file system operation checks
1080 file attribute information.
1081 The client keeps this information cached
1082 for a period of time to reduce network and server load.
1083 When
1084 .B noac
1085 is in effect, a client's file attribute cache is disabled,
1086 so each operation that needs to check a file's attributes
1087 is forced to go back to the server.
1088 This permits a client to see changes to a file very quickly,
1089 at the cost of many extra network operations.
1090 .P
1091 Be careful not to confuse the
1092 .B noac
1093 option with "no data caching."
1094 The
1095 .B noac
1096 mount option prevents the client from caching file metadata,
1097 but there are still races that may result in data cache incoherence
1098 between client and server.
1099 .P
1100 The NFS protocol is not designed to support
1101 true cluster file system cache coherence
1102 without some type of application serialization.
1103 If absolute cache coherence among clients is required,
1104 applications should use file locking. Alternatively, applications
1105 can also open their files with the O_DIRECT flag
1106 to disable data caching entirely.
1107 .SS "Directory entry caching"
1108 The Linux NFS client caches the result of all NFS LOOKUP requests.
1109 If the requested directory entry exists on the server,
1110 the result is referred to as a
1111 .IR positive " lookup result.
1112 If the requested directory entry does not exist on the server
1113 (that is, the server returned ENOENT),
1114 the result is referred to as
1115 .IR negative " lookup result.
1116 .P
1117 To detect when directory entries have been added or removed
1118 on the server,
1119 the Linux NFS client watches a directory's mtime.
1120 If the client detects a change in a directory's mtime,
1121 the client drops all cached LOOKUP results for that directory.
1122 Since the directory's mtime is a cached attribute, it may
1123 take some time before a client notices it has changed.
1124 See the descriptions of the
1125 .BR acdirmin ", " acdirmax ", and " noac
1126 mount options for more information about
1127 how long a directory's mtime is cached.
1128 .P
1129 Caching directory entries improves the performance of applications that
1130 do not share files with applications on other clients.
1131 Using cached information about directories can interfere
1132 with applications that run concurrently on multiple clients and
1133 need to detect the creation or removal of files quickly, however.
1134 The
1135 .B lookupcache
1136 mount option allows some tuning of directory entry caching behavior.
1137 .P
1138 Before kernel release 2.6.28,
1139 the Linux NFS client tracked only positive lookup results.
1140 This permitted applications to detect new directory entries
1141 created by other clients quickly while still providing some of the
1142 performance benefits of caching.
1143 If an application depends on the previous lookup caching behavior
1144 of the Linux NFS client, you can use
1145 .BR lookupcache=positive .
1146 .P
1147 If the client ignores its cache and validates every application
1148 lookup request with the server,
1149 that client can immediately detect when a new directory
1150 entry has been either created or removed by another client.
1151 You can specify this behavior using
1152 .BR lookupcache=none .
1153 The extra NFS requests needed if the client does not
1154 cache directory entries can exact a performance penalty.
1155 Disabling lookup caching
1156 should result in less of a performance penalty than using
1157 .BR noac ,
1158 and has no effect on how the NFS client caches the attributes of files.
1159 .P
1160 .SS "The sync mount option"
1161 The NFS client treats the
1162 .B sync
1163 mount option differently than some other file systems
1164 (refer to
1165 .BR mount (8)
1166 for a description of the generic
1167 .B sync
1168 and
1169 .B async
1170 mount options).
1171 If neither
1172 .B sync
1173 nor
1174 .B async
1175 is specified (or if the
1176 .B async
1177 option is specified),
1178 the NFS client delays sending application
1179 writes to the server
1180 until any of these events occur:
1181 .IP
1182 Memory pressure forces reclamation of system memory resources.
1183 .IP
1184 An application flushes file data explicitly with
1185 .BR sync (2),
1186 .BR msync (2),
1187 or
1188 .BR fsync (3).
1189 .IP
1190 An application closes a file with
1191 .BR close (2).
1192 .IP
1193 The file is locked/unlocked via
1194 .BR fcntl (2).
1195 .P
1196 In other words, under normal circumstances,
1197 data written by an application may not immediately appear
1198 on the server that hosts the file.
1199 .P
1200 If the
1201 .B sync
1202 option is specified on a mount point,
1203 any system call that writes data to files on that mount point
1204 causes that data to be flushed to the server
1205 before the system call returns control to user space.
1206 This provides greater data cache coherence among clients,
1207 but at a significant performance cost.
1208 .P
1209 Applications can use the O_SYNC open flag to force application
1210 writes to individual files to go to the server immediately without
1211 the use of the
1212 .B sync
1213 mount option.
1214 .SS "Using file locks with NFS"
1215 The Network Lock Manager protocol is a separate sideband protocol
1216 used to manage file locks in NFS version 2 and version 3.
1217 To support lock recovery after a client or server reboot,
1218 a second sideband protocol --
1219 known as the Network Status Manager protocol --
1220 is also required.
1221 In NFS version 4,
1222 file locking is supported directly in the main NFS protocol,
1223 and the NLM and NSM sideband protocols are not used.
1224 .P
1225 In most cases, NLM and NSM services are started automatically,
1226 and no extra configuration is required.
1227 Configure all NFS clients with fully-qualified domain names
1228 to ensure that NFS servers can find clients to notify them of server reboots.
1229 .P
1230 NLM supports advisory file locks only.
1231 To lock NFS files, use
1232 .BR fcntl (2)
1233 with the F_GETLK and F_SETLK commands.
1234 The NFS client converts file locks obtained via
1235 .BR flock (2)
1236 to advisory locks.
1237 .P
1238 When mounting servers that do not support the NLM protocol,
1239 or when mounting an NFS server through a firewall
1240 that blocks the NLM service port,
1241 specify the
1242 .B nolock
1243 mount option. NLM locking must be disabled with the
1244 .B nolock
1245 option when using NFS to mount
1246 .I /var
1247 because
1248 .I /var
1249 contains files used by the NLM implementation on Linux.
1250 .P
1251 Specifying the
1252 .B nolock
1253 option may also be advised to improve the performance
1254 of a proprietary application which runs on a single client
1255 and uses file locks extensively.
1256 .SS "NFS version 4 caching features"
1257 The data and metadata caching behavior of NFS version 4
1258 clients is similar to that of earlier versions.
1259 However, NFS version 4 adds two features that improve
1260 cache behavior:
1261 .I change attributes
1262 and
1263 .IR "file delegation" .
1264 .P
1265 The
1266 .I change attribute
1267 is a new part of NFS file and directory metadata
1268 which tracks data changes.
1269 It replaces the use of a file's modification
1270 and change time stamps
1271 as a way for clients to validate the content
1272 of their caches.
1273 Change attributes are independent of the time stamp
1274 resolution on either the server or client, however.
1275 .P
1276 A
1277 .I file delegation
1278 is a contract between an NFS version 4 client
1279 and server that allows the client to treat a file temporarily
1280 as if no other client is accessing it.
1281 The server promises to notify the client (via a callback request) if another client
1282 attempts to access that file.
1283 Once a file has been delegated to a client, the client can
1284 cache that file's data and metadata aggressively without
1285 contacting the server.
1286 .P
1287 File delegations come in two flavors:
1288 .I read
1289 and
1290 .IR write .
1291 A
1292 .I read
1293 delegation means that the server notifies the client
1294 about any other clients that want to write to the file.
1295 A
1296 .I write
1297 delegation means that the client gets notified about
1298 either read or write accessors.
1299 .P
1300 Servers grant file delegations when a file is opened,
1301 and can recall delegations at any time when another
1302 client wants access to the file that conflicts with
1303 any delegations already granted.
1304 Delegations on directories are not supported.
1305 .P
1306 In order to support delegation callback, the server
1307 checks the network return path to the client during
1308 the client's initial contact with the server.
1309 If contact with the client cannot be established,
1310 the server simply does not grant any delegations to
1311 that client.
1312 .SH "SECURITY CONSIDERATIONS"
1313 NFS servers control access to file data,
1314 but they depend on their RPC implementation
1315 to provide authentication of NFS requests.
1316 Traditional NFS access control mimics
1317 the standard mode bit access control provided in local file systems.
1318 Traditional RPC authentication uses a number
1319 to represent each user
1320 (usually the user's own uid),
1321 a number to represent the user's group (the user's gid),
1322 and a set of up to 16 auxiliary group numbers
1323 to represent other groups of which the user may be a member.
1324 .P
1325 Typically, file data and user ID values appear unencrypted
1326 (i.e. "in the clear") on the network.
1327 Moreover, NFS versions 2 and 3 use
1328 separate sideband protocols for mounting,
1329 locking and unlocking files,
1330 and reporting system status of clients and servers.
1331 These auxiliary protocols use no authentication.
1332 .P
1333 In addition to combining these sideband protocols with the main NFS protocol,
1334 NFS version 4 introduces more advanced forms of access control,
1335 authentication, and in-transit data protection.
1336 The NFS version 4 specification mandates NFSv4 ACLs,
1337 RPCGSS authentication, and RPCGSS security flavors
1338 that provide per-RPC integrity checking and encryption.
1339 Because NFS version 4 combines the
1340 function of the sideband protocols into the main NFS protocol,
1341 the new security features apply to all NFS version 4 operations
1342 including mounting, file locking, and so on.
1343 RPCGSS authentication can also be used with NFS versions 2 and 3,
1344 but does not protect their sideband protocols.
1345 .P
1346 The
1347 .B sec
1348 mount option specifies the RPCGSS security mode
1349 that is in effect on a given NFS mount point.
1350 Specifying
1351 .B sec=krb5
1352 provides cryptographic proof of a user's identity in each RPC request.
1353 This provides strong verification of the identity of users
1354 accessing data on the server.
1355 Note that additional configuration besides adding this mount option
1356 is required in order to enable Kerberos security.
1357 Refer to the
1358 .BR rpc.gssd (8)
1359 man page for details.
1360 .P
1361 Two additional flavors of Kerberos security are supported:
1362 .B krb5i
1363 and
1364 .BR krb5p .
1365 The
1366 .B krb5i
1367 security flavor provides a cryptographically strong guarantee
1368 that the data in each RPC request has not been tampered with.
1369 The
1370 .B krb5p
1371 security flavor encrypts every RPC request
1372 to prevent data exposure during network transit; however,
1373 expect some performance impact
1374 when using integrity checking or encryption.
1375 Similar support for other forms of cryptographic security (such as lipkey and SPKM3)
1376 is also available.
1377 .P
1378 The NFS version 4 protocol allows
1379 clients and servers to negotiate among multiple security flavors
1380 during mount processing.
1381 However, Linux does not yet implement such negotiation.
1382 The Linux client specifies a single security flavor at mount time
1383 which remains in effect for the lifetime of the mount.
1384 If the server does not support this flavor,
1385 the initial mount request is rejected by the server.
1386 .SS "Using non-privileged source ports"
1387 NFS clients usually communicate with NFS servers via network sockets.
1388 Each end of a socket is assigned a port value, which is simply a number
1389 between 1 and 65535 that distinguishes socket endpoints at the same
1390 IP address.
1391 A socket is uniquely defined by a tuple that includes the transport
1392 protocol (TCP or UDP) and the port values and IP addresses of both
1393 endpoints.
1394 .P
1395 The NFS client can choose any source port value for its sockets,
1396 but usually chooses a
1397 .I privileged
1398 port.
1399 A privileged port is a port value less than 1024.
1400 Only a process with root privileges may create a socket
1401 with a privileged source port.
1402 .P
1403 The exact range of privileged source ports that can be chosen is
1404 set by a pair of sysctls to avoid choosing a well-known port, such as
1405 the port used by ssh.
1406 This means the number of source ports available for the NFS client,
1407 and therefore the number of socket connections that can be used
1408 at the same time,
1409 is practically limited to only a few hundred.
1410 .P
1411 As described above, the traditional default NFS authentication scheme,
1412 known as AUTH_SYS, relies on sending local UID and GID numbers to identify
1413 users making NFS requests.
1414 An NFS server assumes that if a connection comes from a privileged port,
1415 the UID and GID numbers in the NFS requests on this connection have been
1416 verified by the client's kernel or some other local authority.
1417 This is an easy system to spoof, but on a trusted physical network between
1418 trusted hosts, it is entirely adequate.
1419 .P
1420 Roughly speaking, one socket is used for each NFS mount point.
1421 If a client could use non-privileged source ports as well,
1422 the number of sockets allowed,
1423 and thus the maximum number of concurrent mount points,
1424 would be much larger.
1425 .P
1426 Using non-privileged source ports may compromise server security somewhat,
1427 since any user on AUTH_SYS mount points can now pretend to be any other
1428 when making NFS requests.
1429 Thus NFS servers do not support this by default.
1430 They explicitly allow it usually via an export option.
1431 .P
1432 To retain good security while allowing as many mount points as possible,
1433 it is best to allow non-privileged client connections only if the server
1434 and client both require strong authentication, such as Kerberos.
1435 .SS "Mounting through a firewall"
1436 A firewall may reside between an NFS client and server,
1437 or the client or server may block some of its own ports via IP
1438 filter rules.
1439 It is still possible to mount an NFS server through a firewall,
1440 though some of the
1441 .BR mount (8)
1442 command's automatic service endpoint discovery mechanisms may not work; this
1443 requires you to provide specific endpoint details via NFS mount options.
1444 .P
1445 NFS servers normally run a portmapper or rpcbind daemon to advertise
1446 their service endpoints to clients. Clients use the rpcbind daemon to determine:
1447 .IP
1448 What network port each RPC-based service is using
1449 .IP
1450 What transport protocols each RPC-based service supports
1451 .P
1452 The rpcbind daemon uses a well-known port number (111) to help clients find a service endpoint.
1453 Although NFS often uses a standard port number (2049),
1454 auxiliary services such as the NLM service can choose
1455 any unused port number at random.
1456 .P
1457 Common firewall configurations block the well-known rpcbind port.
1458 In the absense of an rpcbind service,
1459 the server administrator fixes the port number
1460 of NFS-related services so that the firewall
1461 can allow access to specific NFS service ports.
1462 Client administrators then specify the port number
1463 for the mountd service via the
1464 .BR mount (8)
1465 command's
1466 .B mountport
1467 option.
1468 It may also be necessary to enforce the use of TCP or UDP
1469 if the firewall blocks one of those transports.
1470 .SS "NFS Access Control Lists"
1471 Solaris allows NFS version 3 clients direct access
1472 to POSIX Access Control Lists stored in its local file systems.
1473 This proprietary sideband protocol, known as NFSACL,
1474 provides richer access control than mode bits.
1475 Linux implements this protocol
1476 for compatibility with the Solaris NFS implementation.
1477 The NFSACL protocol never became a standard part
1478 of the NFS version 3 specification, however.
1479 .P
1480 The NFS version 4 specification mandates a new version
1481 of Access Control Lists that are semantically richer than POSIX ACLs.
1482 NFS version 4 ACLs are not fully compatible with POSIX ACLs; as such,
1483 some translation between the two is required
1484 in an environment that mixes POSIX ACLs and NFS version 4.
1485 .SH FILES
1486 .TP 1.5i
1487 .I /etc/fstab
1488 file system table
1489 .SH BUGS
1490 The generic
1491 .B remount
1492 option is not fully supported.
1493 Generic options, such as
1494 .BR rw " and " ro
1495 can be modified using the
1496 .B remount
1497 option,
1498 but NFS-specific options are not all supported.
1499 The underlying transport or NFS version
1500 cannot be changed by a remount, for example.
1501 Performing a remount on an NFS file system mounted with the
1502 .B noac
1503 option may have unintended consequences.
1504 The
1505 .B noac
1506 option is a mixture of a generic option,
1507 .BR sync ,
1508 and an NFS-specific option
1509 .BR actimeo=0 .
1510 .P
1511 Before 2.4.7, the Linux NFS client did not support NFS over TCP.
1512 .P
1513 Before 2.4.20, the Linux NFS client used a heuristic
1514 to determine whether cached file data was still valid
1515 rather than using the standard close-to-open cache coherency method
1516 described above.
1517 .P
1518 Starting with 2.4.22, the Linux NFS client employs
1519 a Van Jacobsen-based RTT estimator to determine retransmit
1520 timeout values when using NFS over UDP.
1521 .P
1522 Before 2.6.0, the Linux NFS client did not support NFS version 4.
1523 .P
1524 Before 2.6.8, the Linux NFS client used only synchronous reads and writes
1525 when the
1526 .BR rsize " and " wsize
1527 settings were smaller than the system's page size.
1528 .P
1529 The Linux NFS client does not yet support
1530 certain optional features of the NFS version 4 protocol,
1531 such as security negotiation, server referrals, and named attributes.
1532 .SH "SEE ALSO"
1533 .BR fstab (5),
1534 .BR mount (8),
1535 .BR umount (8),
1536 .BR mount.nfs (5),
1537 .BR umount.nfs (5),
1538 .BR exports (5),
1539 .BR netconfig (5),
1540 .BR ipv6 (7),
1541 .BR nfsd (8),
1542 .BR sm-notify (8),
1543 .BR rpc.statd (8),
1544 .BR rpc.idmapd (8),
1545 .BR rpc.gssd (8),
1546 .BR rpc.svcgssd (8),
1547 .BR kerberos (1)
1548 .sp
1549 RFC 768 for the UDP specification.
1550 .br
1551 RFC 793 for the TCP specification.
1552 .br
1553 RFC 1094 for the NFS version 2 specification.
1554 .br
1555 RFC 1813 for the NFS version 3 specification.
1556 .br
1557 RFC 1832 for the XDR specification.
1558 .br
1559 RFC 1833 for the RPC bind specification.
1560 .br
1561 RFC 2203 for the RPCSEC GSS API protocol specification.
1562 .br
1563 RFC 3530 for the NFS version 4 specification.