Comment 14 for bug 1922293

This looks a lot like an issue with zfs-linux to me (and *maybe* systemd, not sure about this).

The issue is that the snaps are on /var/lib/snapd/snaps and snapd writes mount units into /etc/systemd/system/ so that the snaps are mounted under /snap/<snapname>/<rev>.

Looking at a zfs-linux system and the "mount" output /var/lib is mounted:

$ mount |grep var/lib
rpool/ROOT/ubuntu_azzm5v/var/lib on /var/lib type zfs (rw,relatime,xattr,posixacl)

and the systemd unit for this mount point is auto-generated:
$ systemctl status var-lib.mount
var-lib.mount - /var/lib
     Loaded: loaded (/proc/self/mountinfo)
     Active: active (mounted) since Tue 2021-04-06 16:38:58 CEST; 19min ago
      Where: /var/lib
       What: rpool/ROOT/ubuntu_azzm5v/var/lib

Systemd should order mounts so that var-lib.mount is mounted before What=/var/lib/snapd/... is used. I see a zfs-generator in the zfs-linux source tree that looks like it should generator the mount entries from the pool. However nothing generated in /run/systemd/generator:

$ find /run/systemd/generator
/run/systemd/generator
/run/systemd/generator/netplan.stamp
/run/systemd/generator/openvpn.service.wants
/run/systemd/generator/local-fs.target.wants
/run/systemd/generator/local-fs.target.wants/systemd-remount-fs.service
/run/systemd/generator/swap.target.requires
/run/systemd/generator/swap.target.requires/dev-disk-by\x2duuid-9c43c866\x2dbe89\x2d499c\x2d9300\x2d098d5dcb0509.swap
/run/systemd/generator/dev-disk-by\x2duuid-9c43c866\x2dbe89\x2d499c\x2d9300\x2d098d5dcb0509.swap
/run/systemd/generator/boot-grub.mount
/run/systemd/generator/local-fs.target.requires
/run/systemd/generator/local-fs.target.requires/boot-grub.mount
/run/systemd/generator/local-fs.target.requires/boot-efi.mount
/run/systemd/generator/boot-efi.mount

We could easily workaround this via Pawels approach above but I feel this will affect more than snapd. Everyone who wants to mount anyting under /var/lib will be affected.