NFSv3 writes underneath mounted filesystem to directory
If there is a hierarchy of file systems (e.g. ZFS datasets) shared via NFSv2 and/or NFSv3, the NFS client is required to explicitly mount the subshare to cross the file systems. Without the mounting of the subshare, the NFS client won't see the other file system, but the mount point itself. If the NFS client have right to write to the mount point it can do so. Here is an example:
Preparation on the server:
# zfs create -p rpool/data/test # share -o anon=0 /rpool/data #
Do this on the client:
# mount -o vers=3 SERVER:/rpool/data /mnt # touch /mnt/test/a #
Try the following on the server:
# zfs umount rpool/data/test # zfs mount rpool/data/test cannot mount '/rpool/data/test': directory is not empty #
This NFSv2/NFSv3 behavior (the ability to see the mount point, not the mounted file system) is well known and it is required by the NFS specification (RFC 1813, section 3.3.3).
In a case the ZFS mount point is not empty, the "zfs mount -a" will fail to mount such dataset. This could have various fatal consequences, for example the boot of the machine might fail. There is no similar problem with other file systems. For details please see bug #5579. To workaround this problem with ZFS, we will add a check to both NFSv2 and NFSv3 to protect the empty ZFS mount points.
Updated by Marcel Telka over 7 years ago
The NFSv4 behavior is completely different than in NFSv2/3:
- on lookup, the NFSv4 server always traverses to the mounted filesystem:
- on modify, the NFSv4 server always make sure the directory is not a mountpoint, for example here:
This is because the NFSv4 RFC allowed/requested for that (for example in section 7.7. in RFC 7530).