Quoting Tim Connors

I've got one for you; just came in on the mailing list (someone got stale mounts when their kernel nfs server restarted):

...

ZFS and the NFS kernel server are not that tightly integrated.

When you do a 'zfs set sharenfs="foo,bar" pool/vol' of a 'zfs share pool/vol', the zfs tools just give a call to the NFS kernel server saying 'Hey I want you to share this over NFS'.

That's what it should do. Under FreeBSD it sends a HUP to mountd - that's it.

...

If the NFS kernel server is restarted it unshares everything and only reads back whatever is in /etc/exports. This is actually expected as NFS doesn't know anything about ZFS. Doing a 'zfs share -a' exports all your NFS/SMB shares again.

Yes, it is a dependency. In general /etc/init.d or /etc/rc.d .. scripts take care of it so there is room for improvement if it is not done yet.

...

When you don't use your system native tools, or when someone tries to solve something at the wrong layer (zfs trying to mess around with NFS?

It uses - it just has another list as /etc/exports. It's not a big deal, I would think. ZFS changes the way to work with filesystems in may ways. Who would create/clone/destry/move around filesystems as I do with ZFS now? I have 164 ZFS filesystems on the system I just queried. It makes sense to keep the list of exports here. On a ZFS system, /etc/exports is a "legacy file". BTW: the ZFS hierarchy gives you better control access to parts of the directory than on other filesystems, because it is easy to create a new ZFS for a directory tree and give it different export options. Regards Peter