RAIDZ2 pool DEGRADED after reboot; missing vdev GUIDs still readable via zdb

Hardwareinfo: TrueNAS version: TrueNAS SCALE 24.10.2.4 / Electric Eel

  1. Motherboard: ASRock Rack X470D4U2-2T
  2. CPU: AMD Ryzen 5 3600X
  3. Boot device: SK hynix 32GB M.2 SATA SSD
    • currently appears as /dev/sde

    • serial: ES67N110810507P9W

  4. Main pool: TheBig
    • 6 x 12TB HDD

    • RAIDZ2

    • mix of Seagate IronWolf / Exos-class drives

  5. NVMe pool: NVME
    • 1 x ~2TB NVMe SSD

    • serial: 21376D801551

TrueNAS SCALE 24.10.2.4 / Electric Eel

I’m looking for guidance before running any repair/replacement commands.

I have a 6 x 12TB RAIDZ2 pool named TheBig. It was healthy before reboot. No drive replacements, no reinstall, no intentional pool changes, and I do not believe I upgraded immediately before this happened.

This happened when I rebooted to try to reset Plex. I had put the NAS behind a VPN on my router, but undid that because it caused connection issues with plex.

After reboot, the pool/datasets disappeared from the GUI. TrueNAS showed disks with exported pools. I did not create a new pool or add disks.

Initial command-line import showed both pools as available and ONLINE:

/sbin/zpool import

pool: TheBig
id: 10158275043973833898
state: ONLINE
config:

    TheBig                                    ONLINE
      raidz2-0                                ONLINE
        sdd2                                  ONLINE
        sdg2                                  ONLINE
        sdc2                                  ONLINE
        sda2                                  ONLINE
        11ddf7f4-94bb-4cae-ac82-45d585a69710  ONLINE
        sdb2                                  ONLINE

pool: NVME
id: 9608143190421123067
state: ONLINE
config:

    NVME                                    ONLINE
      e30a35c1-48d9-45fc-809d-3aa1112b3119  ONLINE

Manual import succeeded, but datasets failed to mount because ZFS tried to mount the pool roots at /TheBig and /NVME instead of /mnt/TheBig and /mnt/NVME:

/sbin/zpool import NVME
cannot mount '/NVME': failed to create mountpoint: Read-only file system
Import was successful, but unable to mount some datasets

/sbin/zpool import TheBig
cannot mount '/TheBig': failed to create mountpoint: Read-only file system
Import was successful, but unable to mount some datasets

zfs get mountpoint showed:

NAME    PROPERTY    VALUE       SOURCE
TheBig  mountpoint  /TheBig     default

NAME  PROPERTY    VALUE       SOURCE
NVME  mountpoint  /NVME       default

TrueNAS middleware, however, reported the pools as ONLINE with paths under /mnt:

midclt call pool.query

TheBig:
"path": "/mnt/TheBig"
"status": "ONLINE"

NVME:
"path": "/mnt/NVME"
"status": "ONLINE"

I rebooted again. After that, TheBig came up DEGRADED.

Current zpool status -P:

pool: TheBig
state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid. Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.

config:

    NAME                                                            STATE     READ WRITE CKSUM
    TheBig                                                          DEGRADED     0     0     0
      raidz2-0                                                      DEGRADED     0     0     0
        17554408218717640207                                        FAULTED      0     0     0  was /dev/sdd2
        /dev/sdg2                                                   ONLINE       0     0     0
        11710781531430353535                                        REMOVED      0     0     0  was /dev/sdc2
        /dev/sda2                                                   ONLINE       0     0     0
        /dev/disk/by-partuuid/11ddf7f4-94bb-4cae-ac82-45d585a69710  ONLINE       0     0     0
        /dev/sdb2                                                   ONLINE       0     0     0

errors: No known data errors

The part that confuses me is that the supposedly missing GUIDs still appear readable from attached disks.

zdb -l /dev/sdf2 | grep "guid:" shows:

pool_guid: 10158275043973833898
top_guid: 2887469638244621148
guid: 17554408218717640207

That is the same GUID currently reported as FAULTED:

17554408218717640207 FAULTED was /dev/sdd2

Also, zdb -l /dev/sdd2 shows a valid ZFS label for the same pool and reports:

pool_guid: 10158275043973833898
top_guid: 2887469638244621148
guid: 11710781531430353535

That is the GUID currently reported as REMOVED:

11710781531430353535 REMOVED was /dev/sdc2

lsblk -o NAME,SIZE,SERIAL currently shows:

NAME         SIZE SERIAL
sda         10.9T ZHZ0F25X
├─sda1         2G
└─sda2      10.9T
sdb         10.9T ZHZ05Z4H
├─sdb1         2G
└─sdb2      10.9T
sdc         10.9T ZTN00AWM
└─sdc1      10.9T
sdd         10.9T ZHZ463HS
├─sdd1         2G
└─sdd2      10.9T
sde         29.8G ES67N110810507P9W
├─sde1       260M
└─sde2      29.6G
sdf         10.9T ZHZ5RWM2
├─sdf1         2G
└─sdf2      10.9T
sdg         10.9T ZHZ5X5FW
├─sdg1         2G
└─sdg2      10.9T
nvme0n1      1.8T 21376D801551
└─nvme0n1p1  1.8T

One oddity: /dev/sdc has only one large ZFS partition, while the other pool disks mostly have a 2G swap partition plus a ZFS partition.

sgdisk -p /dev/sdc:

Disk /dev/sdc: 23437770752 sectors, 10.9 TiB
Model: ST12000NE0008-2P
Disk identifier (GUID): 4E273AC5-190C-4647-9F0B-9C4A4B3F1EBF

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048     23437768703   10.9 TiB    BF01  data

blkid /dev/sdc*:

/dev/sdc1: LABEL="TheBig" UUID="10158275043973833898" UUID_SUB="8444992749518646930" BLOCK_SIZE="4096" TYPE="zfs_member" PARTLABEL="data" PARTUUID="11ddf7f4-94bb-4cae-ac82-45d585a69710"

sgdisk -p /dev/sdd:

Disk /dev/sdd: 23437770752 sectors, 10.9 TiB
Model: ST12000VN0008-2J
Disk identifier (GUID): 3D4AB86B-661D-11EA-92C3-D05099D5BDEA

Number  Start (sector)    End (sector)  Size       Code  Name
   1             128         4194431   2.0 GiB     A502
   2         4194432     23437770711   10.9 TiB    A504

blkid /dev/sdd*:

/dev/sdd1: LABEL="freenas:swap0" TYPE="linux_raid_member"
/dev/sdd2: LABEL="TheBig" UUID="10158275043973833898" UUID_SUB="11710781531430353535" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="3da59291-661d-11ea-92c3-d05099d5bdea"

Relevant /dev/disk/by-partuuid links:

11ddf7f4-94bb-4cae-ac82-45d585a69710 -> ../../sdc1
3da59291-661d-11ea-92c3-d05099d5bdea -> ../../sdd2

SMART short attributes on the drives I checked are clean:

Reallocated_Sector_Ct   0
Current_Pending_Sector  0
Offline_Uncorrectable   0

for:

/dev/sdc
/dev/sdf
/dev/sdd

zpool history TheBig | tail -50 shows no recent replace/remove/detach operations. The last relevant entry appears to be:

2026-06-01.16:17:21 zpool import TheBig

I also tried:

sudo /sbin/zpool import -d /dev/disk/by-id TheBig

but it returned:

cannot import 'TheBig': a pool with that name already exists
use the form 'zpool import <pool | id> <newpool>' to give it a new name

and:

sudo /sbin/zpool import -d /dev/disk/by-id

returned:

no pools available to import

because the pool is already imported, though degraded.

Question:

What is the safest recovery path here?

I have not run zpool replace, zpool clear, zpool detach, wiped labels, or repartitioned anything.

Given that the vdev GUIDs reported as FAULTED/REMOVED appear to still be readable via zdb -l from attached disks, and SMART looks clean, I’m trying to understand whether this is a device mapping / stale import / label issue rather than actual disk failure.

I want to avoid making the situation worse by replacing or clearing the wrong device.
I’ll be looking through the other topics here… Thanks for any help. additional hardware info below:

DDR4_A1

Kingston

Product Name

DIMM

Product Part Number

9965745-041.A00G

Product Serial Number

9416BD90

Product Extra

2666 MT/s 32GB

DDR4_A2

Product Manufacturer Name

Kingston

Product Name

DIMM

Product Part Number

9965745-002.A00G

Product Serial Number

205C0E53

Product Extra

2666 MT/s 16GB

DDR4_B1

Product Manufacturer Name

Kingston

Product Name

DIMM

Product Part Number

9965745-022.A00G

Product Serial Number

4A6E24ED

Product Extra

2666 MT/s 32GB

DDR4_B2

Product Manufacturer Name

Kingston

Product Name

DIMM

Product Part Number

9965745-002.A00G

255C0B95

Product Extra

2666 MT/s 16GB

Storage (SATA3_0)

Product Part Number

ST12000VN0008-2JH101

ZHZ05Z4H

Storage (SATA3_1)

ST12000VN0008-2JH101

ZHZ0F25X

Storage (SATA3_2)

ST12000NE0008-2PK103

ZTN00AWM

Storage (SATA3_3)

ST12000VN0008-2JH101

ZHZ463HS

Storage (SATA3_4)

ST12000NE0008-2JL101

ZHZ5RWM2

Storage (SATA3_5)

ST12000NE0008-2JL101

ZHZ5X5FW

Storage (M2_1(PCIE))

WDC WDS200T2B0C-00PXH0

21376D801551

Storage (M2_2(SATA))

SK hynix SC215 M.2 2242 32GB

ES67N110810507P9W

Anything of note in dmesg? I once had a port fail (regardless of sata cable) & would get weird blips of sata port speed changes before the drive would fail out.

Hopefully this is as simple as a loose connection or something stupid. I have no other recommendations.

Thanks for that….

I checked dmesg and journalctl for SATA/AHCI/link/reset/CRC/timeout/failed-command messages.

I do not see obvious SATA reset or link instability messages for the pool drives. The SATA controller initializes normally, the main ports come up at 6.0 Gbps, and I don’t see hard resetting link, soft resetting link, SError, CRC, failed command, I/O error, timeout, or frozen messages for the affected devices.

The only SATA link down entries I see are for ata9 and ata10, which appear to be unused ports/controllers, not the pool disks.

The later journal output mostly contains normal smartd temperature attribute changes for /dev/sdc, /dev/sdd, /dev/sdf, etc.

So at least from the logs I checked, I don’t see clear evidence of a bad SATA port/cable, although I’m not ruling out a physical connection issue entirely.

Good news though! I just took it out, blew everything out, reseated the cables like you suggested… It came back online!

TheBig state: ONLINE
resilvered 18.3M in 00:00:14 with 0 errors
errors: No known data errors

A couple warnings…

sde2 ONLINE 0 0 3
sdd2 ONLINE 0 0 3

I’m going to run a scrub, and monitor for errors, but hopefully this is fixed. I’ll followup if anything is unusual. Thanks for your advice!

Update, all seems well. Scrub finished successfully, and short SMART tests have been successful as well. I’ll wait for the regularly scheduled extended SMART to complete on its own. Back to a healthy system as far as I can tell. Thanks again.