Posted 25 March, 2020
ZFS has this less documented feature, called share[nfs|smb]; I tried it once, it “did not work on first attempt”™ So I ignored it; However now we faced an issue where we normally exported ZFS volumes using /etc/exports (NFS); and mounted using /etc/fstab; but got an empty directory where there was a “sub” zpool volume; This seems counter intuitive as on the NFS exporting system you don’t see any difference in child pools directory structure;
For example : (on NFS server)
[[email protected] /]# zfs list NAME USED AVAIL REFER MOUNTPOINT tinky 31.4T 49.0T 256K /tinky tinky/archive 219K 49.0T 219K /tinky/archive tinky/upload 219K 49.0T 219K /tinky/upload
In order to export the full /tinky directory; we should do the following in /etc/exports :
This we can mount; and should give :
/tinky /tinky/archive /tinky/upload
Which it does, yaaay ! Wrong ! All the data stored under /tinky/archive and /tinky/upload is invisible on the mount ! In fact these directories are empty.
Since zpool children are really easy (unlike human children) it would be really annoying to have to create a /etc/export and /etc/fstab entry for each of those childeren; There is a better way; using sharenfs option in ZFS and autofs (which I played around with already before, here).
In order to start the share with ZFS simply do :
zfs sharenfs=on tinky
You can check the result :
[[email protected] /]# zfs get all | grep nfs tinky sharenfs on local tinky/archive sharenfs on inherited from tinky tinky/upload sharenfs on inherited from tinky
[[email protected] ~]# showmount -e Export list for tinky: /tinky * /tinky/archive * /tinky/upload *
If you want to restrict the shares or adapt the options; you can use :
zfs set sharenfs='[email protected]/16,[email protected]/24' tinky
in this case I restrict to two IP ranges; but go crazy. On issuing this command, they are automatically exported; which you can verify using exportfs
[[email protected] /]# exportfs /tinky/upload 192.168.20.0/24 /tinky/archive 192.168.20.0/24
note : reduced output.
In case you don’t see it, you can try to share manually :
zfs share -a
and surprising, if you wish to un-share :
zfs unshare -a
On the remote machine, you can verify if you have access to the NFS mounts using showmount -e , using the IP of the NFS server;
# showmount -e 192.168.20.208 Export list for 192.168.20.208: /tinky 192.168.20.0/24 /tinky/archive 192.168.20.0/24 /tinky/upload 192.168.20.0/24
The auto-mount itself now seems smarter then before; although I’m unsure exactly how, simply adding the root of the share is enough to see all the subvolumes in ZFS :
tinky -rw,hard,intr,rsize=32768,wsize=32768,nfsvers=3\ /tinky 192.168.20.208:/tinky
Happy ZFS sharing 😉
Turns out the issue is still there with this method;
// update 2
might be required :
systemctl nfs-server enable systemctl nfs-server start
If you enjoyed this article, please consider buying me a Dr Pepper.
Fuel the beast!
Buy me a Dr Pepper