{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/",
        "slug": "explain-openzfs-snapshot-deletion-failures-through-tagged-holds",
        "url": "https://update.dsesecurity.com/updates/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/explain-openzfs-snapshot-deletion-failures-through-tagged-holds.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/"
        },
        "title": "Explain OpenZFS snapshot deletion failures through tagged holds",
        "summary": "Inspect snapshot hold tags and their owners before trying to resolve an EBUSY deletion refusal.",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "priority": {
            "slug": "info",
            "name": "Information"
        },
        "featured": false,
        "image": {
            "theme": "continuity-recovery",
            "label": "Continuity & recovery",
            "alt": "Paired infrastructure paths converging on a stable recovered service.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "business-continuity",
                "name": "Business Continuity",
                "url": "https://update.dsesecurity.com/topic/business-continuity/"
            },
            {
                "slug": "it",
                "name": "IT",
                "url": "https://update.dsesecurity.com/topic/it/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-10-15T13:32:48+00:00",
        "modified_at": "2026-10-15T13:36:15+00:00",
        "reviewed_on": "2026-10-15",
        "reading_minutes": 2,
        "word_count": 251,
        "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.",
        "primary_source": {
            "name": "OpenZFS 2.3 — zfs hold",
            "url": "https://openzfs.github.io/openzfs-docs/man/v2.3/8/zfs-hold.8.html",
            "published_on": null,
            "authority": "openzfs.github.io"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<p>Inspect snapshot hold tags and their owners before trying to resolve an EBUSY deletion refusal.</p>\n<h2>Source facts</h2>\n<p>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.</p>\n<p>Source: <a href=\"https://openzfs.github.io/openzfs-docs/man/v2.3/8/zfs-hold.8.html\">OpenZFS 2.3 — zfs hold</a>.</p>\n<h2>Applicability</h2>\n<p>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.</p>\n<h2>DSE recommendation</h2>\n<p>DSE recommends inspecting the exact snapshot&#8217;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.</p>\n<h2>Verification</h2>\n<p>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.</p>\n<h2>Official reference</h2>\n<p><a href=\"https://openzfs.github.io/openzfs-docs/man/v2.3/8/zfs-hold.8.html\">OpenZFS 2.3 — zfs hold</a>. Reviewed October 15, 2026.</p>",
        "content_text": "Inspect snapshot hold tags and their owners before trying to resolve an EBUSY deletion refusal.\nSource facts\nOpenZFS 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.\nSource: OpenZFS 2.3 — zfs hold.\nApplicability\nThis 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.\nDSE recommendation\nDSE 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.\nVerification\nIn 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.\nOfficial reference\nOpenZFS 2.3 — zfs hold. Reviewed October 15, 2026.",
        "content_markdown": "Inspect snapshot hold tags and their owners before trying to resolve an EBUSY deletion refusal.\n\n## Source facts\n\nOpenZFS 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.\n\nSource: [OpenZFS 2.3 — zfs hold](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zfs-hold.8.html).\n\n## Applicability\n\nThis 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.\n\n## DSE recommendation\n\nDSE 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.\n\n## Verification\n\nIn 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.\n\n## Official reference\n\n[OpenZFS 2.3 — zfs hold](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zfs-hold.8.html). Reviewed October 15, 2026."
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/",
                "url": "https://update.dsesecurity.com/updates/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-10-15"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Explain OpenZFS snapshot deletion failures through tagged holds",
                        "item": "https://update.dsesecurity.com/updates/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/#article",
                "identifier": "https://update.dsesecurity.com/updates/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/",
                "url": "https://update.dsesecurity.com/updates/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/",
                "headline": "Explain OpenZFS snapshot deletion failures through tagged holds",
                "description": "Inspect snapshot hold tags and their owners before trying to resolve an EBUSY deletion refusal.",
                "abstract": "Inspect snapshot hold tags and their owners before trying to resolve an EBUSY deletion refusal.",
                "articleBody": "Inspect snapshot hold tags and their owners before trying to resolve an EBUSY deletion refusal.\nSource facts\nOpenZFS 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.\nSource: OpenZFS 2.3 — zfs hold.\nApplicability\nThis 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.\nDSE recommendation\nDSE 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.\nVerification\nIn 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.\nOfficial reference\nOpenZFS 2.3 — zfs hold. Reviewed October 15, 2026.",
                "datePublished": "2026-10-15T13:32:48+00:00",
                "dateModified": "2026-10-15T13:36:15+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/explain-openzfs-snapshot-deletion-failures-through-tagged-holds/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Explain OpenZFS snapshot deletion failures through tagged holds"
                },
                "articleSection": [
                    "Business Continuity",
                    "IT"
                ],
                "keywords": [
                    "Business Continuity",
                    "IT",
                    "Guide",
                    "Information priority"
                ],
                "genre": "Guide",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "Business Continuity",
                        "url": "https://update.dsesecurity.com/topic/business-continuity/"
                    },
                    {
                        "@type": "Thing",
                        "name": "IT",
                        "url": "https://update.dsesecurity.com/topic/it/"
                    }
                ],
                "wordCount": 251,
                "timeRequired": "PT2M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "OpenZFS 2.3 — zfs hold",
                    "url": "https://openzfs.github.io/openzfs-docs/man/v2.3/8/zfs-hold.8.html"
                }
            }
        ]
    }
}