Data on ZFS dataset mysteriously gone? It’s almost never actually gone. It’s a mountpoint, a bind mount, or a pool that didn’t import cleanly. Check those before you panic.
Check the pool state first
If the pool itself is suspended or faulted, nothing mounts. Run zpool status and look at the state column. If it says SUSPENDED, that’s your problem — and it’s fixable without data loss. I wrote about that exact situation in ZFS Pool Suspended: Offline the Disk, Clear the Errors, Online It Again.
zpool statusIf the pool is ONLINE but the dataset is empty, move on.
Is the dataset actually mounted?
ZFS datasets have a mountpoint property. If it’s set to legacy, ZFS won’t mount it automatically — something else has to. If it’s set to a path but that path is also used by another filesystem, the mount silently fails or the wrong thing shows up.
zfs list -r -o name,mountpoint,mountedLook for mounted being no. If so, try mounting it manually and see what error you get.
zfs mount tank/datasetIf it says the mountpoint is not empty, that’s your clue. Something else is mounted there, hiding your data.
Check for bind mounts in containers
If this is inside an LXC container, Proxmox bind mounts the dataset into the container. But if the container’s config has the mount point wrong, or the dataset isn’t mounted on the host first, the container just sees an empty directory.
On the host, check /etc/pve/lxc/<CTID>.conf for lines like:
mp0: /tank/dataset,mp=/mnt/dataMake sure the host path is the actual mountpoint of the dataset, not a parent directory. And make sure the dataset is mounted before the container starts. If the container starts first, it gets an empty directory and the bind mount never happens.
My take
Nine times out of ten, it’s a mountpoint conflict or a bind mount that didn’t happen. The data is still there. Don’t go restoring from backups until you’ve checked these three things in order. It’s a five-minute check that saves you an afternoon of restore work.
