Explain OpenZFS snapshot deletion failures through tagged holds

Inspect snapshot hold tags and their owners before trying to resolve an EBUSY deletion refusal.

Source facts

OpenZFS 2.3 supports named holds on snapshots. Each snapshot has its own tag namespace, and a tag must be unique within that snapshot. While any hold remains, an attempted snapshot destruction returns EBUSY. The holds command lists the user references, and release removes a named reference that already exists. Recursive hold and release options operate on matching snapshots in descendant filesystems. Releasing one tag does not mean that every other hold has been removed.

Source: OpenZFS 2.3 — zfs hold.

Applicability

This applies to OpenZFS 2.3 snapshot hold diagnosis and administration. It concerns the technical reason for a deletion refusal, rather than a legal retention policy or evidence-lock certification.

DSE recommendation

DSE recommends inspecting the exact snapshot’s hold list before interpreting a failed cleanup as a storage fault. Map operational tags to their owner and purpose, including replication or maintenance dependencies. Have that owner approve any release, and review the recursive target scope before acting. Preserve the observed tags in the change record so a future operator can explain why deletion was previously blocked. Avoid automated release of every tag merely to make a cleanup task report success.

Verification

In a disposable dataset, apply two distinct holds, observe the deletion refusal, and release only one. Verify the remaining hold still prevents destruction. Check descendant behavior separately if recursion is intended, and retain the resulting hold inventory as the expected administrative evidence.

Official reference

OpenZFS 2.3 — zfs hold. Reviewed October 15, 2026.