ZFS is unable to import encrypted ZFS datasets, and nfs-server zfs mounts are inaccessible without a manual reload.

[GNY-001F2]

The current runit script does not seem to take into account encrypted ZFS datasets.

void-runit/core-services/03-filesystems.sh

Lines 33 to 52 in 8ab6d40

	if [ -x /usr/bin/zpool -a -x /usr/bin/zfs ]; then
	if [ -e /etc/zfs/zpool.cache ]; then
	msg "Importing cached ZFS pools..."
	zpool import -N -a -c /etc/zfs/zpool.cache
	else
	msg "Scanning for and importing ZFS pools..."
	zpool import -N -a -o cachefile=none
	fi
	msg "Mounting ZFS file systems..."
	zfs mount -a
	msg "Sharing ZFS file systems..."
	zfs share -a
	# NOTE(dh): ZFS has ZVOLs, block devices on top of storage pools.
	# In theory, it would be possible to use these as devices in
	# dmraid, btrfs, LVM and so on. In practice it's unlikely that
	# anybody is doing that, so we aren't supporting it for now.
	fi

I added a simple zfs load-key -a to the script between the zpool import and zfs mount blocks, but my keyfiles are not loaded. I believe this probably because my keyfile is located outside the / file system.

So I moved the entire block containing zfs code to the end of the script, after all partitions are mounted. However I'm sure this will break systems which rely on ZFS datasets to be mounted before mounting the fstab entries. So maybe the zfs block should be run twice? The first block remains in its original place while the second block serves as a sort of catch-all for the secondary mount points that rely on a mounted partitions.

This also brings me to my second problem: my zfs mounts do not use the auto-sharing properties, so zfs share, as I understand it, does not share my mount points during boot. However I do have the shares configured in /etc/exports and I expect nfs server to share them properly. However the shares are inaccessible unless I restart nfs-server manually after ssh'ing into the server. I do have port 2049 opened in nftables.conf, and my client machine uses the mount option nfs4.

[ahesford]

Encrypted filesystems should be mounted properly in #59.

Regarding your second issue: I suspect that the zfs share command is probably a no-op unless nfsd or smbd (for sharenfs or sharesmb, respectively) are already running, which happens long after 03-filesystems.sh is invoked. There is not really a clean way to handle this with runit.

Your best bet is probably to fire a one-shot runit service that does whatever checks are appropriate to determine whether nfsd is running and, when so, runs zfs share -a and then exec pause.

[ahesford]

I misread the second half of your issue, please disregard my comments, which seem inaccurate for NFS anyway after reading through the ZFS share code.

If you have key files on filesystems other than ZFS, then it makes sense that trying to zfs mount before the other filesystems are in place will never work as expected. Having two rounds of ZFS mounting to work around this is a clumsy solution. The ZFS pools should definitely be imported and mounted before fstab mounts, because ZFS automounts are intended to supersede legacy fstab mounts. For situations where ZFS must interplay with legacy mounts, ZFS offers a legacy mountpoint to give the administrator full control.

There are two reasonable ways to handle keys for automatic unlocking:

• Use raw keys dumped straight to different partitions, so there is no need for mounting before ZFS uses the keys; or
• Put your key files on the root or somewhere in the ZFS automount hierarchy so they will always be available

Using zfs mount -a -l as in #59 is reasonable because it only tries to load keys for filesystems it actually indents to mount. Using zfs load-key -a is not a good general solution because it will attempt to load all keys regardless of whether the operator intends for those filesystems to be unlocked and mounted.

If you need legacy mounts before ZFS does its mounts, you are looking for custom behavior, and the only reasonable place to do this is in /etc/rc.local, where you lose the benefit of early mounting of ZFS.

[GNY-001F2]

@ahesford: Ah, I ended up migrating that server to a different distribution long ago. Completely forgot that this issue was still open. My apologies.