Data confirmed intact via zdb, but zpool import structurally blocked — now stuck on zdb -B 'Permission denied' (TrueNAS SCALE, ZFS 2.3.4)

TrueNAS General
, ,
1

Background: 2-disk mirror pool (2x4TB WD Red Plus) on a ZimaBlade running TrueNAS SCALE 25.10.5 went offline after a brief upgrade-then-revert. zpool import has failed in every mode and flag combination for over a week, always with either “device unavailable” or “insufficient replicas — destroy and re-create.” Full diagnostic history (with a very generous assist from someone working from exact source references) is here:
https://github.com/openzfs/zfs/discussions/18954

Where things stand now, confirmed via source-level analysis:

  • SMART, labels, uberblocks, partition tables: all clean on both disks.

  • zdb -e fully loads the pool’s trusted config (spa_load(..., config trusted): LOADED) — the pool structure and data are intact and readable.

  • The reason zpool import fails in every mode, including readonly and with spa_load_verify_metadata=0: spa_load_verify (spa.c:2831) unconditionally walks every dataset via dmu_objset_find_dp before import can succeed, and one specific object (a DSL props ZAP, object 293) fails checksum (ECKSUM/errno 52) during that walk. This is a hard block — no flag, module parameter, or rewind mode skips it. -F/-X don’t help either, since they re-enable full data verification.

  • A full zdb -bcsvL traversal of the whole pool found only 8 checksum errors total, out of 29.2 million block pointers — and every one of them is confined to pool-internal bookkeeping (SPA space map, DSL props) or disposable .system/samba4 and .system/netdata-* service datasets. None of my actual data datasets (Photos, Documents, Archived, etc.) show any corruption.

Current blocker: Since zpool import can’t succeed, the recommended path is zdb -B (backup stream extraction), which reads a dataset directly without needing a successful import. But every dataset I try — encrypted or not, parent or child, small or large — fails identically:

dump_backup: dmu_send_obj: Permission denied

running as root, 0-byte output, exit code 0. zdb -O/-r (path lookups) also fail, but with a different error (Input/output error), suggesting a different cause than the -B failure.

What I’m hoping this forum specifically can help with:

  • Has anyone seen dmu_send_obj: Permission denied from zdb -B on TrueNAS SCALE specifically? Wondering if this is a TrueNAS-specific build/patch difference from upstream OpenZFS, a SCALE permission/capability restriction, or something environment-specific to this appliance.

  • Is there a TrueNAS-supported/documented path for exactly this scenario (pool won’t import, but data is confirmed readable via zdb) that I’m missing — official data-recovery tooling, a support channel, or a known workaround for zdb -B on SCALE?

Not time-pressured, happy to provide any further diagnostics. Two 4TB drives, ~3TB used, non-time-sensitive personal data — just trying to get it off before doing anything destructive to the pool.