Your Share Looks Empty After a TrueNAS Update. Don't Roll Back the ZFS Dataset Yet.

Written and maintained by the Desert Data Recovery lab team. · Updated October 16, 2026

We already wrote about a TrueNAS pool that will not import, about zpool import -F as a rewind, and about a scrub that found checksum errors. This page is the pool that did import. SMB or NFS opened, or an app did. The directory you expected is empty. zfs rollback is the command people reach for. It does not check whether the share is pointed at a different dataset.

An empty folder is not a space reading

zfs list is a read. The default columns are NAME, USED, AVAIL, REFER, and MOUNTPOINT. OpenZFS defines REFER as the amount of data accessible by that dataset, which may or may not be shared with other datasets in the pool. USED is the space consumed by that dataset and all of its descendants. A directory listing with no files does not set REFER to zero. If the dataset the share is supposed to serve still shows a large REFER, the blocks are still referenced. The listing is the wrong view of them.

zfs list -t snapshot is the same read for snapshots. Write the names down. On a snapshot, USED means something narrower: space referenced only by that snapshot. Space shared with the live dataset, or with another snapshot, is not counted there. A snapshot taken while the files were still in place can show a small USED and a large REFER, because the live dataset still shares those blocks. A small USED is not an empty snapshot. Do not destroy it to tidy the list.

Compare rows before you decide anything was deleted. The dataset you expected, the dataset the share's Path actually names, ix-applications if this box ran apps before the update, and the dataset mounted at /mnt/.ix-apps after a 24.10 upgrade. A drop on one row and the same data still referenced on another row is a different location. A drop on the dataset that held the files, with no other dataset and no snapshot still referencing them, is the point where you stop writing. Rollback is not how you put that number back.

The share path and the mountpoint are two different strings

On TrueNAS 24.10, an SMB share's Path is the directory tree on the local filesystem that TrueNAS exports. It is on the share itself: Shares, Windows Shares (SMB), then the share. An NFS share has the same kind of field under Shares, Unix (NFS) Shares. Later releases can move the screen. The thing you need is the path the share exports, not the share's display name. Write that path down next to the MOUNTPOINT column. If they differ, the client is not looking at the dataset you think it is.

MOUNTPOINT is a property: a path, none, or legacy. canmount is a separate property. off means the filesystem cannot be mounted. noauto means it is not mounted when the pool is imported; someone has to mount it explicitly. Either one leaves the path you are browsing as an ordinary directory on the parent dataset. The files that belong to the unmounted dataset are not in that directory. zfs get mountpoint,canmount prints both. zfs set changes them.

Do not zfs set mountpoint to drag the files back to the share. OpenZFS unmounts the filesystem when the mountpoint changes, remounts it at the new location unless the new value is legacy, and unshares and reshares it. That is a change to where the dataset is presented. It is not a check. On Linux, which is what TrueNAS SCALE is, the overlay property defaults to on. A dataset is allowed to mount on a directory that already contains files. Those files stay on the parent and are hidden for as long as the other dataset is mounted there. They were not deleted by the mount. An empty dataset mounted at the old path produces an empty share. Read which dataset is mounted at that path, and what its REFER is, before you destroy the empty one or roll anything back.

The Add SMB and Add NFS screens both have a Create Dataset button. It creates a new dataset and points the share's Path at it. A dataset created that way has no files in it yet. The dataset you had yesterday is a different row in zfs list, if nobody has destroyed it. Re-adding the share onto a new dataset is how an empty folder gets a familiar name.

Permissions do the same kind of trick without moving a block. If a root shell on the TrueNAS box lists the files at the dataset's mountpoint, and the SMB or NFS client does not, the client is not seeing the dataset. That can be the Path, or the ACL on that path. TrueNAS documents Edit Filesystem ACL as the screen that changes the ACL on the dataset the share uses. Opening it and saving a new ACL is a write. Reading zfs list and listing the mountpoint from a shell is not. The 24.10 notes also say auxiliary SMB parameters can change between major versions and can cause SMB share failures after an upgrade. A share that fails, while REFER is unchanged, is a share problem. Rolling the dataset back does not answer it.

24.10 moved the app dataset. The old one is still a dataset.

TrueNAS 24.10, Electric Eel, moved the Apps backend from Kubernetes to Docker. The release notes describe the upgrade from 24.04 (Dragonfish). Supported official-catalog apps migrate to Docker on that upgrade. During the migration, 24.10 creates a hidden Docker dataset on the apps pool, mounted at /mnt/.ix-apps. It reads the Kubernetes data in the previous ix-applications dataset, ports it, and saves it in the new dataset. App-storage ixVolumes that were in ix-applications are cloned under the new dataset and promoted. The previous ix-applications dataset is retained, which is what keeps a boot back to Dragonfish able to run those apps. TrueNAS 24.10 does not run its current apps out of ix-applications.

The Datasets screen hides the new dataset. zfs list does not. Find the row whose mountpoint is /mnt/.ix-apps, and find ix-applications. They are not two views of one folder. A file browser or a share pointed at one of them is not showing you the other. iXsystems' app-storage note says any modification of the hidden ix-apps dataset can lose app function. Leave its mountpoint alone. Leave ix-applications alone too, until both rows are accounted for. Deleting the old dataset is the step the docs allow only after you have confirmed the migration and you do not need to boot 24.04 again. An empty app screen is not that confirmation. A revert to 24.04 without ix-applications has no app data.

Two documented cases never fill the new dataset from the old one. Applications from third-party catalogs, TrueCharts included, do not automatically migrate. The notes say that migration generally means a manual backup and a redeploy, and that those catalogs are not maintained by iXsystems. Applications also do not migrate when ix-applications is on a pool with an encrypted dataset (the notes cite NAS-131561). In both cases the old dataset is still the dataset. A new install of the app, pointed at a new host path or a new ixVolume, starts empty. The files you had are on the dataset the old app was using, until someone destroys that dataset.

Host-path ACL settings are a pre-upgrade item in the same notes, not a repair for today. Apps on 24.04 that used a host path with Enable ACL and ACL entries were supposed to have the Force checkbox set before the upgrade, so the mount would migrate when the path already had data. Setting that flag, or rewriting the ACL now to "make the folder come back," writes permissions. Do not. The release notes also document a shell job that re-runs a failed Kubernetes-to-Docker migration. That job is what clones and promotes ixVolumes. Do not start it while you are still trying to see which dataset holds the files, and do not delete the dataset it reads.

A custom app installed from the 24.04 UI does migrate, per those notes. If it had nonstandard networking, the interface configuration is discarded. That sentence is about the network attachment. It is not a statement that the app's files were discarded. Users who had installed Docker themselves on 24.04 or earlier can have the Apps service fail on 24.10, because that install conflicts with the Docker TrueNAS now runs. An app that will not start is not a dataset to roll back.

"Roll back" in the 24.10 notes means boot the previous TrueNAS release, and it depends on ix-applications still being there. zfs rollback is a different operation. It reverts one dataset to a snapshot. Running it against the share, against ix-applications, or against the new apps dataset does not boot Dragonfish, and deleting ix-applications does not make the new share fill in.

What zfs rollback actually discards

The OpenZFS manual is the whole feature. zfs rollback reverts the dataset to the snapshot. All data that has changed since that snapshot is discarded. The default command refuses to roll back to any snapshot except the most recent one. The flag that gets past the refusal is -r. It destroys snapshots and bookmarks more recent than the snapshot you named. -R destroys those newer snapshots and bookmarks and also destroys clones of them. -f is used with -R to force-unmount clone filesystems that are about to be destroyed.

That destroy is narrower than "every snapshot on the pool." The same manual says -r and -R do not recursively destroy the child snapshots of a recursive snapshot. Only direct snapshots of the filesystem you named are destroyed. Descendant datasets keep their own snapshots until someone rolls those back too. The live changes since the target snapshot are still discarded, and rollback does not take a new snapshot of them first. There is no second copy of Tuesday inside the command.

People add -r because the command refused. The refusal is the stop. The folder looked empty, the snapshot from last month is the one that "had the files," and -r is what makes the command stop refusing. Every snapshot and bookmark of that dataset newer than last month is destroyed on the way. Files written after that snapshot, including files that were only invisible because the share path was wrong, go with them.

This is not zpool import -F. -F is a pool that will not import. It discards transaction groups so the pool can open. zfs rollback is a dataset on a pool that is already imported. Both throw away newer data. Neither one is a test for a wrong path. If the UI offers to roll a snapshot back and warns that newer snapshots will be deleted, that is this operation. Do not confirm it to repopulate a share.

Do not destroy the dataset, the snapshots, or the pool, and do not create a new pool on these disks. "Destroy and re-create the pool from a backup source" is a stock import error. It is covered on the Unraid and TrueNAS page. It is not the next step after an empty folder. A new pool on the same disks is how the old labels stop being the pool you had.

Read the snapshot. Do not roll the dataset back to it.

A filesystem snapshot is read-only. OpenZFS exposes it at .zfs/snapshot in the root of the mounted filesystem. If pool/share is mounted at /mnt/pool/share, the snapshot pool/share@before-upgrade is at /mnt/pool/share/.zfs/snapshot/before-upgrade. The snapdir property defaults to hidden: the directory exists and does not show up in a normal listing. Type the path. You do not have to set snapdir=visible to look, and setting it is a property change you do not need. Copy a file out if you need it. Copy, do not move. A volume has no directory to browse. Snapshot device nodes for a zvol are a different property, snapdev, and this page is not a zvol procedure.

.zfs is only there when the filesystem is mounted. An unmounted dataset still has its snapshots in zfs list -t snapshot. Mounting it read-write, or changing its mountpoint so you can browse .zfs, is how an empty directory gets covered or a share starts writing the dataset you have not finished identifying. If you are not sure the mountpoint directory is empty of files you still need, do not mount over it.

zfs clone creates a new dataset from a snapshot. The new dataset is writable. Its initial contents are the snapshot. The live dataset stays as it is, and newer snapshots stay. The manual's example is zfs clone pool/home/bob@yesterday pool/clone. The target has to be a new name. Do not clone onto the dataset the share is already using, and do not set the clone's mountpoint to the share's path. Read the clone at its own mountpoint. The origin snapshot cannot be destroyed while a clone of it exists.

Promoting the clone reverses that dependency so the original can be destroyed. The OpenZFS manual shows promote, rename, and destroy as the way to replace a filesystem with the clone. That is a replacement. Do not do it while you are still looking for files. Leave the clone as a clone.

A clone writes pool metadata. It is the right shape of command on a pool that is healthy, imported, and not the only copy you are willing to risk. It is the wrong command on a disk that is clicking or dropping out, on a resilver, or on a pool that will not import. Power a failing disk down. See what a clicking drive means. Checksum errors and Replace are the scrub page. Do not start a scrub or a resilver to hunt for a folder that moved.

What to do right now

1. Stop. Do not run zfs rollback, with or without -r, -R, or -f. Do not zfs destroy a dataset, a snapshot, or the pool. Do not create a dataset or a pool on these disks. Do not zfs set mountpoint. Do not re-run the Kubernetes-to-Docker migration, and do not delete ix-applications or edit the hidden apps dataset. Do not rewrite the share ACL, and do not click Create Dataset to give the share a new path.
2. Read zfs list. NAME, USED, REFER, MOUNTPOINT for the pool and the datasets under it. Then zfs get mountpoint,canmount on the dataset the share is supposed to use. Photograph the output. A second run to make it neater is unnecessary. The first one is the record.
3. Read zfs list -t snapshot. Name, USED, and REFER. Judge a snapshot by REFER and by the files inside it, not by a small USED. Leave the snapshots where they are.
4. Read the share path. SMB: Shares, Windows Shares (SMB), Path. NFS: Shares, Unix (NFS) Shares, Path. Compare it to MOUNTPOINT. If this was an app upgrade to 24.10, also look at /mnt/.ix-apps and at ix-applications. From a shell, list the mountpoint the dataset actually has. If root can see the files there and the client cannot, you are done diagnosing a delete. The files are at that mountpoint.
5. If you need an older copy and the pool is healthy, open .zfs/snapshot/<name> on the mounted filesystem, or clone the snapshot to a new dataset name that does not cover the live share. Copy what you need to a different disk. Do not promote the clone. Do not roll the live dataset back afterward because the copy worked.
6. If REFER on the dataset that held the files has actually dropped, and no other dataset or snapshot still references that data, stop writing. Same if the pool will not import, a disk is clicking, or a resilver or a scrub is already chewing through the only copy. Photograph what you have. Power a failing disk down. How to ship a failed drive. Bring every member, including a drive you already called dead and a drive you added during the upgrade. If the pool is encrypted, bring the key. The key unlocks the dataset. It does not recreate files a rollback already discarded.

How a lab handles it

We do not zfs rollback your dataset on your hardware to see if the folder fills in. We do not destroy ix-applications, the hidden apps dataset, or the pool, and we do not create a replacement pool on the original disks. We do not run the app migration again as a test.

Each member is imaged write-blocked first, as far as it will read. The pool is examined on the copies: which dataset still references the space, which snapshot still has the files, which mountpoint the share was exporting. A wrong guess on a copy costs the copy. A rollback on the originals discards the changes on the disks you still have. An empty share path with the space still referenced is a mapping problem. The files are on the dataset whose REFER still accounts for them. A dataset whose referenced space is actually gone, or a pool that will not import, is the other job. It still starts from images. zpool import -F on the patient's disks is the rewind page, and it is not a shortcut we take because the share looked empty.

The public case log has no TrueNAS system and no ZFS pool. We will not invent one. A Synology RAID 5 and an HPE SmartArray are published on that page. They are different layouts. They are not a prediction about a zpool. We don't advertise a success rate, and we can't promise a turnaround from a TrueNAS version number. The evaluation is at Desert Data Recovery, in the Phoenix area. The number on this page is (602) 686-2622. For the set itself, see RAID data recovery.