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