FreeNAS Pool Will Not Mount After Drive Replacement
A FreeNAS pool that stops mounting after a drive replacement may still contain the original datasets. The replacement can expose an incomplete resilver, a missing or stale vdev member, conflicting labels, unreadable metadata, or a pool state that the current system will not import automatically.
Do not create a new pool, clear labels, detach additional members, or repeatedly force the import. Preserve the original drive, replacement drive, bay order, and current pool evidence.
What this condition means
ZFS identifies a pool through member GUIDs, vdev topology, transaction groups, and redundant labels. Seeing every physical disk does not prove that FreeNAS has assembled the same vdev set that last held the data.
A replacement may be healthy yet incomplete. If resilvering did not finish—or another member became unreadable—the safest usable state may involve the original member, the partial replacement, or protected copies of both.
What to record
- FreeNAS version, system model, and controller or HBA
- Exact zpool status and import messages
- Pool name, vdev layout, RAIDZ level, and member count
- Bay, serial number, and role of every original and replacement drive
- Replacement, resilver, detach, offline, import, or reboot history
What not to do
- Create a new pool using the original members
- Clear or overwrite ZFS labels
- Force repeated imports without preserving the current state
- Detach another member or change bay order
- Run repair or destructive tests against the only member set
How ADR evaluates it
ADR compares the vdev identities, ZFS labels, transaction history, member readability, and replacement sequence to determine which sources can represent one consistent pool state.
Stable logical cases may be evaluated remotely. If any member is unstable, imaging comes first; pool reconstruction and dataset validation then proceed from protected sources.
Keep both the original member and the replacement. ADR can evaluate their ZFS labels, vdev roles, transaction history, and readable coverage independently, then reconstruct the most defensible pool state without repeatedly forcing an import.
What happens next
A failed mount after replacement does not mean the datasets were erased. Recoverability depends on readable coverage across the required vdev members and what the replacement or import attempts changed.