SvennD
Sharenfs on ZFS and mounting with autofs
March 25, 2020

Sharenfs on ZFS and mounting with autofs

Posted on March 25, 2020  •  3 minutes  • 453 words  •  Suggest Changes

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)

[root@tinky /]# 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 :

/tinky 127.168.0.0/16(rw,async,no_subtree_check,no_root_squash) 

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 :

[root@tinky /]# zfs get all | grep nfs
tinky                 sharenfs              on                     local
tinky/archive         sharenfs              on                     inherited from tinky
tinky/upload          sharenfs              on                     inherited from tinky

and/or

[root@tinky ~]# 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='rw=@192.0.10.0/16,rw=@192.0.11.0/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

[root@tinky /]# 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 😉

 

// update

Turns out the issue is still there with this method;

// update 2
might be required :

systemctl nfs-server enable
systemctl nfs-server start
Support

If you enjoyed this website, consider buying me a Dr. Pepper

Buy me a Dr PepperBuy me a Dr Pepper