# Explain OpenZFS snapshot deletion failures through tagged holds

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

- Canonical URL: https://update.dsesecurity.com/updates/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T13:32:48+00:00
- Modified: 2026-10-15T13:36:15+00:00
- Last reviewed by DSE: 2026-10-15
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, IT
- Reading time: 2 minutes

## What you need to know

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

## Potentially affected

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.

## Article

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](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zfs-hold.8.html).

## 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](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zfs-hold.8.html). Reviewed October 15, 2026.

## Primary reference

- Name: OpenZFS 2.3 — zfs hold
- Authority: openzfs.github.io
- URL: https://openzfs.github.io/openzfs-docs/man/v2.3/8/zfs-hold.8.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Explain OpenZFS snapshot deletion failures through tagged holds,” DSE Security, https://update.dsesecurity.com/updates/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.