Clarify NFSv4 /etc/exports semantics, with working example.

The existing wording has been confusing users for years.

usr.sbin/mountd/exports.5

@@ -498,6 +498,40 @@ and any client within the 131.104.48 subnet is permitted to perform NFSv4 state
 operations on the server, so long as valid Kerberos credentials are provided.
 The machine grumpy.cis.uoguelph.ca is permitted to perform NFSv4 state
 operations on the server using AUTH_SYS credentials, as well as Kerberos ones.
+.Pp
+In the following example some directories are exported as NFSv3 and NFSv4:
+.Bd -literal -offset indent
+V4: /wingsdl/nfsv4
+/wingsdl/nfsv4/usr-ports -maproot=root -network 172.16.0.0 -mask 255.255.0.0
+/wingsdl/nfsv4/clasper   -maproot=root clasper
+.Ed
+.Pp
+Only one V4: line is needed or allowed to declare where NFSv4 is
+rooted.  The other lines declare specific exported directories with
+their absolute paths given in /etc/exports.
+.Pp
+The exported directories' paths are used for both v3 and v4.
+However, they are interpreted differently for v3 and v4.  A client
+mount command for usr-ports would use the server-absolute name when
+using nfsv3:
+.Bd -literal -offset indent
+mount server:/wingsdl/nfsv4/usr-ports /mnt/tmp
+.Ed
+.Pp
+A mount command using NFSv4 would use the path relative to the NFSv4
+root:
+.Bd -literal -offset indent
+mount server:/usr-ports /mnt/tmp
+.Ed
+.Pp
+This also differentiates which version you want if the client can do
+both v3 and v4.  The former will only ever do a v3 mount and the
+latter will only ever do a v4 mount.
+.Pp
+Note that due to different mount behavior between NFSv3 and NFSv4 a
+NFSv4 mount request for a directory that the client does not have
+permission for will succeed and read/write access will fail
+afterwards, whereas NFSv3 rejects the mount request.
 .Sh SEE ALSO
 .Xr nfsv4 4 ,
 .Xr netgroup 5 ,