I see. I think you may be conflating a few different aspects together though. Although to answer your question directly, the snap package is the only official distribution method for the 4.0 and above version of LXD.
However the mount namespace does not prevent using ZFS tools for all operations, its just that the mount namespace means the containers are not mounted directly on the host.
Perhaps an example would help, this is a fresh ubuntu 20.04 VM with LXD installed from snap:
# Create a ZFS storage pool on a loopback image (although recommend for production is to use a dedicated disk or partition for the zpool).
lxc storage create zfs zfs
# Launch container on ZFS pool.
lxc launch images:ubuntu/focal c1 -s zfs
# Try to use `zfs list` on host:
apt install zfsutils
zfs list
root@v1:/# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zfs 212M 4.15G 24K none
zfs/containers 2.98M 4.15G 24K none
zfs/containers/c1 2.95M 4.15G 208M /var/snap/lxd/common/lxd/storage-pools/zfs/containers/c1
zfs/custom 24K 4.15G 24K none
zfs/deleted 120K 4.15G 24K none
zfs/deleted/containers 24K 4.15G 24K none
zfs/deleted/custom 24K 4.15G 24K none
zfs/deleted/images 24K 4.15G 24K none
zfs/deleted/virtual-machines 24K 4.15G 24K none
zfs/images 208M 4.15G 24K none
zfs/images/c3e80efdcd15823ef2f372955915f94f65a24a0444e5c32dada6a72ba6e31cd8 208M 4.15G 208M /var/snap/lxd/common/lxd/storage-pools/zfs/images/c3e80efdcd15823ef2f372955915f94f65a24a0444e5c32dada6a72ba6e31cd8
zfs/virtual-machines 24K 4.15G 24K none
So the ZFS tool can see the volumes created by LXD inside the snap.
However if I go to mount path /var/snap/lxd/common/lxd/storage-pools/zfs/containers/c1
I can see it is empty from the host, but populated inside the snap’s mount namespace:
root@v1:/# ls -la /var/snap/lxd/common/lxd/storage-pools/zfs/containers/c1
total 8
d--x------ 2 root root 4096 Feb 1 10:02 .
drwx--x--x 3 root root 4096 Feb 1 10:02 ..
root@v1:/# sudo nsenter --mount=/run/snapd/ns/lxd.mnt -- ls -la /var/snap/lxd/common/lxd/storage-pools/zfs/containers/c1
total 11
d--x------ 4 1000000 root 6 Feb 1 10:02 .
drwx--x--x 3 root root 4096 Feb 1 10:02 ..
-r-------- 1 root root 2999 Feb 1 10:02 backup.yaml
-rw-r--r-- 1 root root 526 Jan 31 07:53 metadata.yaml
drwxr-xr-x 17 1000000 1000000 23 Jan 31 07:53 rootfs
drwxr-xr-x 2 root root 4 Jan 31 07:53 templates
If you need to temporarily mount a volume in the host namespace you can too (even while the container is running):
zfs mount zfs/containers/c1
ls -la /var/snap/lxd/common/lxd/storage-pools/zfs/containers/c1
total 11
d--x------ 4 1000000 root 6 Feb 1 10:02 .
drwx--x--x 3 root root 4096 Feb 1 10:02 ..
-r-------- 1 root root 3015 Feb 1 10:14 backup.yaml
-rw-r--r-- 1 root root 526 Jan 31 07:53 metadata.yaml
drwxr-xr-x 17 1000000 1000000 23 Jan 31 07:53 rootfs
drwxr-xr-x 2 root root 4 Jan 31 07:53 templates
However you should ensure its unmounted before the container is stopped as that can cause issues when container is trying to clean up its own mount if the mount is still in use in the other namespace.
The topic of auto snapshots using external tools is separate from mount namespaces though. The reason that using an external tool to create snapshots of an LXD ZFS backed volume may cause issues is that LXD is not aware of them and so if you come to perform an operation on a container (e.g. copy, move, rename, resize, delete etc) it may fail due to not handling the external snapshots or it may result in data loss of the snapshots are removed unexpectedly. Also depending on the name of the snapshots it introduces the possibility at least of naming conflicts.
@stgraber is it possible to still use zfs recovery tools when using LXD with the snap?