When a Simple Drive Swap Turns Into a Blocked Mount — What ZFS Is Really Protecting
Replacing a failed disk in TrueNAS should be straightforward — but after reboot, many admins see an unexpected and alarming outcome:
the pool will not mount, even though the new drive is healthy and no errors appear during boot.
This is not a filesystem failure.
This is ZFS protecting your pool from a suspected identity or consistency problem.
And in most cases, the data remains intact, but TrueNAS needs the correct member state and transaction groups (TXGs) before it will mount safely.
1. Why This Happens After a Drive Replacement
ZFS is far more cautious than hardware RAID.
If the replaced disk arrives with:
- mismatched TXG
- unexpected vdev GUID
- stale ZFS labels
- incomplete resilver metadata
- differing uberblocks
then TrueNAS will refuse to mount the pool to avoid irreversible corruption.
This is not an error — it’s a safety lockout.
2. Identity Drift Between Old and New Members
Even if the new disk is healthy, ZFS expects:
- exact vdev order
- matching ashift values
- synchronized labels on all members
- TXGs within tolerance
- uberblocks with consistent transaction lineage
If anything is out of alignment, the pool will not mount.
This is the most common cause of sudden “Missing” or “Unmountable Pool” states after a replacement.
3. How ZFS Protects the Pool
ZFS compares:
- last valid checkpoint
- latest TXG on each device
- each disk’s embedded ZFS label
- vdev GUIDs
- array topology
If these do not align, ZFS assumes the replacement disk may cause destructive writes and blocks the mount behavior entirely.
4. Symptoms You May See
- Pool won’t import or reports “cannot import pool”
- TrueNAS GUI shows:
- “One or more devices is faulted”
- “Insufficient replicas”
- “Mismatched vdev labels”
- CLI reports:
- “device has a mismatched txg”
- “unable to open vdev”
- “uberblock mismatch”
- Pool appears healthy the moment before the swap — then becomes unmountable
5. What This Means for Your Data
- Pool data is usually intact
- ZFS will not risk a destructive resilver
- TXG mismatches require validation from disk images
- Most pools can be recovered, as long as no forced imports were attempted
- Forcing “zpool import -f” often causes irreversible topology corruption
You replaced a failed drive in your TrueNAS system expecting ZFS to rebuild cleanly — but now your volume won’t mount at all.
What’s Really Happening
In ZFS-based systems like TrueNAS, pool health is deeply tied to metadata consistency and vdev integrity. After replacing a drive:
- ZFS may see the new drive as a mismatch to the expected vdev layout
- Pool import errors can occur if metadata is stale or corrupted
- System may boot but volume remains offline due to unrecognized or partially imported pool
Diagnostic Overview
- Controller: TrueNAS (ZFS)
- Observed State: Pool or Volume Will Not Mount After Drive Replacement
- Likely Cause: TXG mismatch, stale ZFS labels, vdev GUID inconsistency, or incomplete metadata synchronization
- Do NOT: Force import, detach/reattach vdevs, rewrite labels, or run scrub on live members
- Recommended Action: Clone all drives; validate ZFS labels and uberblocks offline; reconstruct correct TXG lineage; rebuild vdev map safely
Back to RAID Controller & Systems Triage