ZFS Datasets

ZFS Datasets

Eligibility

An exact ZFS dataset-backed appdata candidate appears in the ZFS datasets section. An ordinary folder on ZFS is not automatically an independent dataset.

The plugin must resolve the exact mounted dataset and validate its affected paths. A user-share path alone is not proof of which dataset should be destroyed. Use Appdata Sources mappings when the user-share view needs an explicit physical-root association.

Review workflow

1. Open Details and inspect dataset identity, mountpoint and discovery reason.
2. Review children and snapshots that affect the proposed operation.
3. Resolve any ownership or protected-path block.
4. Run Dry run and inspect the actual dataset operation.
5. Only if permanent loss is intended, disable Safe Mode and complete the explicit destruction confirmation.

Exact datasets cannot be moved through the folder quarantine flow. They do not get a plugin restore button after destruction.

Recursive impact

Children and snapshots can require recursive destruction. The impact preview is meaningful: a child dataset may contain separate data or have a different mountpoint. Every affected descendant must pass safety checks, including container, Compose, VM and protected-path checks. Unknown or unsafe descendants prevent proceeding.

ZFS shared blocks and snapshots mean displayed data size is not a guarantee of immediately reclaimed pool space.

Common mapping problem

If appdata is seen as /mnt/user/appdata/example-app but its actual mounted dataset is under /mnt/cache/appdata/example-app, map the roots using the real pool. Then rescan and verify exact resolution. A mapping does not move data, discover new folders or authorize destruction.

The plugin does not create an automatic snapshot, replication copy or ZFS rollback plan before deletion. Independent backups and any desired snapshot/replication preparation remain the administrator's responsibility.