What Causes a ZFS Dataset to Appear Empty After It Mounts Successfully?

A ZFS dataset can report mounted yet look empty when the expected data is on a child dataset, hidden mountpoint, or different import root.

The mounted flag proves that one dataset is attached to one path; it does not prove that the path is the one an application or user expects, that child datasets mounted beneath it, or that an encrypted descendant unlocked. An empty parent dataset can be completely healthy while all real files live in children. Begin by comparing dataset properties, referenced space, mount tables, and the directory view before copying data or changing pool structure.

Compare Dataset Space With the Directory You Opened

Record the dataset name, its USED, REFER, AVAIL, MOUNTPOINT, and MOUNTED values. Then list the exact directory shown to the user or application.

If the dataset reports almost no referenced data, the files may belong to a child dataset, snapshot, clone, or another dataset with a similar name. The FreeBSD ZFS handbook describes datasets as separately managed filesystems, so pool-level usage and one opened directory do not necessarily represent the same dataset.

Do not infer data loss from the graphical file browser alone. Compare the ZFS property view, the operating system’s mount table, and a local root shell that is outside any container or restricted application namespace.

Verify mountpoint, mounted, and canmount Together

Check whether the dataset’s mountpoint is explicit or inherited, whether it is actually mounted at that path, and whether canmount is on, off, or noauto.

Oracle’s ZFS property guidance explains that mountpoint and canmount determine whether a dataset is mounted automatically, mounted only when requested, or used only to pass properties to descendants.

A dataset can supply inherited properties to its children while remaining intentionally unmounted itself. Conversely, a dataset using a legacy mountpoint can appear correct in ZFS properties but depend on a separate system mount entry that did not run.

Inspect Parent and Child Dataset Mounts

List the complete dataset tree beneath the pool and sort it by mountpoint. Compare the parent dataset with every child that should contain user files, app data, backups, or media.

An empty parent is common when it exists only to organize properties and mountpoints. The FreeBSD ZFS dataset namespace treats each child as its own managed dataset, so pool/data may be empty while pool/data/photos holds the actual files.

If the parent mounts but a child does not, diagnose the child independently. Check canmount, encryption keys, conflicting mountpoints, failed imports, and whether a service started before the child mount completed.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Check Whether the Mount Hid Files Already in the Directory

Files can exist in the ordinary directory before a dataset mounts over it. Once the ZFS dataset is mounted, those underlying files are hidden from the path even though they remain on the root filesystem.

Unmount the dataset only during a controlled maintenance window and inspect the underlying directory from the host. The Linux mount manual states that pre-existing mountpoint contents become invisible while the mounted filesystem occupies that path.

The reverse failure also occurs: an expected ZFS mount fails, leaving the empty underlying directory visible to users and containers. That can make a healthy dataset look empty even though it is simply not attached to the path being served.

Rule Out Alternate Root and Legacy Mount Behavior

Check whether the pool was imported with an alternate root, recovery option, temporary mount path, or different pool name. A dataset may be mounted successfully under a prefixed recovery path rather than its normal production location.

Importing a pool with an alternate root rewrites dataset mount locations relative to that temporary root. Ubuntu’s zpool import reference documents that -R sets altroot, while -N can import without mounting filesystems.

Also inspect datasets whose mountpoint is legacy. In that mode, ZFS does not manage the mount automatically, so the operating system’s mount configuration becomes the source of truth.

Check Encrypted Children and Container Mount Namespaces

An encrypted child dataset can remain unavailable after its parent mounts if the key was not loaded or the child mount failed. The parent directory then appears empty or incomplete even though the pool is online.

Verify key status and mount state for every encrypted descendant, then compare the host path with the path presented to the container. Canonical’s LXD documentation explains that container disk devices map host sources to separate instance paths, so a host-visible child dataset can still be absent from an older container mount.

If the host sees the data but a container does not, inspect the container’s bind source and mount propagation. A container created before the ZFS child mounted may continue seeing the underlying empty directory until the service is recreated or the mount is propagated correctly.

Restore the Correct View Without Copying the Dataset

Fix the smallest proven property or path: mount the missing child, correct an inherited mountpoint, remove an unintended alternate root, repair the legacy mount entry, load the encryption key, or recreate the container with the correct bind source.

The ZimaSpace home server recovery checklist provides the adjacent rule: verify the storage layer and mount state before running repair tools or restoring data.

The diagnosis is complete when the expected dataset and child mounts appear at the intended paths, referenced space matches visible files, applications see the same tree as the host, and the layout survives export, import, service restart, and reboot.