xref: /freebsd/usr.sbin/nfsd/nfsv4.4 (revision 4436b51dff5736e74da464946049ea6899a88938)
1.\" Copyright (c) 2009 Rick Macklem, University of Guelph
2.\" All rights reserved.
3.\"
4.\" Redistribution and use in source and binary forms, with or without
5.\" modification, are permitted provided that the following conditions
6.\" are met:
7.\" 1. Redistributions of source code must retain the above copyright
8.\"    notice, this list of conditions and the following disclaimer.
9.\" 2. Redistributions in binary form must reproduce the above copyright
10.\"    notice, this list of conditions and the following disclaimer in the
11.\"    documentation and/or other materials provided with the distribution.
12.\"
13.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
14.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
15.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
16.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
17.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
18.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
19.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
20.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
21.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
22.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
23.\" SUCH DAMAGE.
24.\"
25.\" $FreeBSD$
26.\"
27.Dd July 1, 2013
28.Dt NFSV4 4
29.Os
30.Sh NAME
31.Nm NFSv4
32.Nd NFS Version 4 Protocol
33.Sh DESCRIPTION
34The NFS client and server provides support for the
35.Tn NFSv4
36specification; see
37.%T "Network File System (NFS) Version 4 Protocol RFC 3530" .
38The protocol is somewhat similar to NFS Version 3, but differs in significant
39ways.
40It uses a single compound RPC that concatenates operations to-gether.
41Each of these operations are similar to the RPCs of NFS Version 3.
42The operations in the compound are performed in order, until one of
43them fails (returns an error) and then the RPC terminates at that point.
44.Pp
45It has
46integrated locking support, which implies that the server is no longer
47stateless.
48As such, the
49.Nm
50server remains in recovery mode for a grace period (always greater than the
51lease duration the server uses) after a reboot.
52During this grace period, clients may recover state but not perform other
53open/lock state changing operations.
54To provide for correct recovery semantics, a small file described by
55.Xr stablerestart 5
56is used by the server during the recovery phase.
57If this file is missing or empty, there is a backup copy maintained by
58.Xr nfsd 8
59that will be used. If either file is missing, they will be
60created by the
61.Xr nfsd 8 .
62If both the file and the backup copy are empty,
63it will result in the server starting without providing a grace period
64for recovery.
65Note that recovery only occurs when the server
66machine is rebooted, not when the
67.Xr nfsd 8
68are just restarted.
69.Pp
70It provides several optional features not present in NFS Version 3:
71.sp
72.Bd -literal -offset indent -compact
73- NFS Version 4 ACLs
74- Referrals, which redirect subtrees to other servers
75  (not yet implemented)
76- Delegations, which allow a client to operate on a file locally
77.Ed
78.Pp
79The
80.Nm
81protocol does not use a separate mount protocol and assumes that the
82server provides a single file system tree structure, rooted at the point
83in the local file system tree specified by one or more
84.sp 1
85.Bd -literal -offset indent -compact
86V4: <rootdir> [-sec=secflavors] [host(s) or net]
87.Ed
88.sp 1
89line(s) in the
90.Xr exports 5
91file.
92(See
93.Xr exports 5
94for details.)
95The
96.Xr nfsd 8
97allows a limited subset of operations to be performed on non-exported subtrees
98of the local file system, so that traversal of the tree to the exported
99subtrees is possible.
100As such, the ``<rootdir>'' can be in a non-exported file system.
101The exception is ZFS, which checks exports and, as such, all ZFS file systems
102below the ``<rootdir>'' must be exported.
103However,
104the entire tree that is rooted at that point must be in local file systems
105that are of types that can be NFS exported.
106Since the
107.Nm
108file system is rooted at ``<rootdir>'', setting this to anything other
109than ``/'' will result in clients being required to use different mount
110paths for
111.Nm
112than for NFS Version 2 or 3.
113Unlike NFS Version 2 and 3, Version 4 allows a client mount to span across
114multiple server file systems, although not all clients are capable of doing
115this.
116.Pp
117.Nm
118uses names for users and groups instead of numbers.
119On the wire, they
120take the form:
121.sp
122.Bd -literal -offset indent -compact
123<user>@<dns.domain>
124.Ed
125.sp
126where ``<dns.domain>'' is not the same as the DNS domain used
127for host name lookups, but is usually set to the same string.
128Most systems set this ``<dns.domain>''
129to the domain name part of the machine's
130.Xr hostname 1
131by default.
132However, this can normally be overridden by a command line
133option or configuration file for the daemon used to do the name<->number
134mapping.
135Under FreeBSD, the mapping daemon is called
136.Xr nfsuserd 8
137and has a command line option that overrides the domain component of the
138machine's hostname.
139For use of
140.Nm ,
141either client or server, this daemon must be running.
142If this ``<dns.domain>'' is not set correctly or the daemon is not running, ``ls -l'' will typically
143report a lot of ``nobody'' and ``nogroup'' ownerships.
144.Pp
145Although uid/gid numbers are no longer used in the
146.Nm
147protocol, they will still be in the RPC authentication fields when
148using AUTH_SYS (sec=sys), which is the default.
149As such, in this case both the user/group name and number spaces must
150be consistent between the client and server.
151.Pp
152However, if you run
153.Nm
154with RPCSEC_GSS (sec=krb5, krb5i, krb5p), only names and KerberosV tickets
155will go on the wire.
156.Sh SERVER SETUP
157To set up the NFS server that supports
158.Nm ,
159you will need to either set the variables in
160.Xr rc.conf 5
161as follows:
162.sp
163.Bd -literal -offset indent -compact
164nfs_server_enable="YES"
165nfsv4_server_enable="YES"
166nfsuserd_enable="YES"
167.Ed
168.sp
169or start
170.Xr mountd 8
171and
172.Xr nfsd 8
173without the ``-o'' option, which would force use of the old server.
174The
175.Xr nfsuserd 8
176daemon must also be running.
177.Pp
178You will also need to add at least one ``V4:'' line to the
179.Xr exports 5
180file for
181.Nm
182to work.
183.Pp
184If the file systems you are exporting are only being accessed via
185.Nm
186there are a couple of
187.Xr sysctl 8
188variables that you can change, which might improve performance.
189.Bl -tag -width Ds
190.It Cm vfs.nfsd.issue_delegations
191when set non-zero, allows the server to issue Open Delegations to
192clients.
193These delegations permit the client to manipulate the file
194locally on the client.
195Unfortunately, at this time, client use of
196delegations is limited, so performance gains may not be observed.
197This can only be enabled when the file systems being exported to
198.Nm
199clients are not being accessed locally on the server and, if being
200accessed via NFS Version 2 or 3 clients, these clients cannot be
201using the NLM.
202.It Cm vfs.nfsd.enable_locallocks
203can be set to 0 to disable acquisition of local byte range locks.
204Disabling local locking can only be done if neither local accesses
205to the exported file systems nor the NLM is operating on them.
206.El
207.sp
208Note that Samba server access would be considered ``local access'' for the above
209discussion.
210.Pp
211To build a kernel with the NFS server that supports
212.Nm
213linked into it, the
214.sp
215.Bd -literal -offset indent -compact
216options	NFSD
217.Ed
218.sp
219must be specified in the kernel's
220.Xr config 5
221file.
222.Sh CLIENT MOUNTS
223To do an
224.Nm
225mount, specify the ``nfsv4'' option on the
226.Xr mount_nfs 8
227command line.
228This will force use of the client that supports
229.Nm
230plus set ``tcp'' and
231.Nm .
232.Pp
233The
234.Xr nfsuserd 8
235must be running, as above.
236Also, since an
237.Nm
238mount uses the host uuid to identify the client uniquely to the server,
239you cannot safely do an
240.Nm
241mount when
242.sp
243.Bd -literal -offset indent -compact
244hostid_enable="NO"
245.Ed
246.sp
247is set in
248.Xr rc.conf 5 .
249.sp
250If the
251.Nm
252server that is being mounted on supports delegations, you can start the
253.Xr nfscbd 8
254daemon to handle client side callbacks.
255This will occur if
256.sp
257.Bd -literal -offset indent -compact
258nfsuserd_enable="YES"
259nfscbd_enable="YES"
260.Ed
261.sp
262are set in
263.Xr rc.conf 5 .
264.sp
265Without a functioning callback path, a server will never issue Delegations
266to a client.
267.sp
268By default, the callback address will be set to the IP address acquired via
269rtalloc() in the kernel and port# 7745.
270To override the default port#, a command line option for
271.Xr nfscbd 8
272can be used.
273.sp
274To get callbacks to work when behind a NAT gateway, a port for the callback
275service will need to be set up on the NAT gateway and then the address
276of the NAT gateway (host IP plus port#) will need to be set by assigning the
277.Xr sysctl 8
278variable vfs.nfs.callback_addr to a string of the form:
279.sp
280N.N.N.N.N.N
281.sp
282where the first 4 Ns are the host IP address and the last two are the
283port# in network byte order (all decimal #s in the range 0-255).
284.Pp
285To build a kernel with the client that supports
286.Nm
287linked into it, the option
288.sp
289.Bd -literal -offset indent -compact
290options	NFSCL
291.Ed
292.sp
293must be specified in the kernel's
294.Xr config 5
295file.
296.Pp
297Options can be specified for the
298.Xr nfsuserd 8
299and
300.Xr nfscbd 8
301daemons at boot time via the ``nfsuserd_flags'' and ``nfscbd_flags''
302.Xr rc.conf 5
303variables.
304.Pp
305NFSv4 mount(s) against exported volume(s) on the same host are not recommended,
306since this can result in a hung NFS server.
307It occurs when an nfsd thread tries to do an NFSv4 VOP_RECLAIM()/Close RPC
308as part of acquiring a new vnode.
309If all other nfsd threads are blocked waiting for lock(s) held by this nfsd
310thread, then there isn't an nfsd thread to service the Close RPC.
311.Sh FILES
312.Bl -tag -width /var/db/nfs-stablerestart.bak -compact
313.It Pa /var/db/nfs-stablerestart
314NFS V4 stable restart file
315.It Pa /var/db/nfs-stablerestart.bak
316backup copy of the file
317.El
318.Sh SEE ALSO
319.Xr stablerestart 5 ,
320.Xr mountd 8 ,
321.Xr nfscbd 8 ,
322.Xr nfsd 8 ,
323.Xr nfsdumpstate 8 ,
324.Xr nfsrevoke 8 ,
325.Xr nfsuserd 8
326.Sh BUGS
327At this time, there is no recall of delegations for local file system
328operations.
329As such, delegations should only be enabled for file systems
330that are being used solely as NFS export volumes and are not being accessed
331via local system calls nor services such as Samba.
332