Unraid 7.2.4. 16-disk array (single parity), running fine except for Disk 15.

Disk: ST8000DM004-2CX188, serial ZCT05AS7, 8TB, assigned as Disk 15 (was /dev/sdi)

How it started: Disk 15 showed as Unmountable in the Main tab, File system type auto, no red X / not disabled — just unmountable.

SMART report: Overall self-assessment PASSED. Reallocated_Sector_Ct = 0, Current_Pending_Sector = 0, Offline_Uncorrectable = 0, no errors in the extended comprehensive error log. Temps normal (37–42°C). So SMART looks clean — doesn't look like a failing drive.

Steps taken so far:

1. Started array in Maintenance Mode, ran xfs_repair -v /dev/md15p1 on the physical disk.

   • Result: bad primary superblock - bad magic number, then scanned for a secondary superblock for ~12 hours, ended with Sorry, could not find valid secondary superblock. Exiting now.

2. Confirmed parity is valid (last correcting check completed 4 days prior, 0 errors, 2 days 15 hours duration).

3. Stopped array, unassigned Disk 15, started array in Maintenance Mode again so Disk 15 is now emulated from parity + the other 14 data disks.

4. Ran xfs_repair -v /dev/md15p1 again against the emulated disk. it also came back withbad primary superblock - bad magic number. Secondary scan still running.

Question: Since parity was valid/in-sync before I noticed the corruption, I suspect parity may have synced right along with whatever damaged the superblock, so the emulated copy may carry the same damage as the physical disk. Is there anything else worth trying before I move to raw recovery tools (testdisk/photorec) or accept data loss and reformat? Is it worth checking fdisk -l or lsblk output on the physical disk to see if the partition table itself looks intact? Diagnostics attached.

mediaserv-safemode-diagnostics-20260807-1019.zip

You can try upgrading to 7.3.2 since it includes newer xfs_progs, but most likely the result will be the same, if that's the case, and assuming no backups, best bet is to use a file recovery app, like UFS Explorer; the free trial should show what it can recover; the app costs around $60 last time I checked.

Thanks for you response. I'm going to pull Disk 15 and attempt recovery with UFS Explorer, copying anything it finds to a separate, brand new disk (not writing back to Disk 15 itself).

Two questions on the Unraid side once that's done:

1. Getting a clean disk back into the Disk 15 slot: since both the physical disk and the parity-emulated copy hit identical "no valid secondary superblock" corruption, a standard rebuild-from-parity would just reproduce the same broken filesystem again. Is Tools → New Config (keeping the 14 good disks + parity assignments, then formatting Disk 15 fresh) the right way to avoid that, or is there a more direct path when reassigning a disk to a slot that's currently marked missing?

2. Reusing the original disk: is it safe to put the same physical disk back in, or does this corruption pattern suggest an underlying hardware issue I should treat as disqualifying? SMART came back clean (Reallocated_Sector_Ct / Current_Pending_Sector / Offline_Uncorrectable all 0, overall self-assessment PASSED), so it doesn't look like a failing drive to me, but wanted your read on it.

You can do a new config; parity will need to be resynched.

It should not be a disk problem, though if it happens again to the same disk without an apparent reason, it could be.

Update: the unmountable disk was not actually a long-time array member

Correction to my earlier posts. I had assumed the 8TB Seagate (ST8000DM004-2CX188_ZCT05AS7) had been Disk 15 for a long time before becoming unmountable. The logs show otherwise.

I checked syslog-previous from a flash backup about six weeks before the problem. At that time, slot 15 was empty:

mdcmd (17): import 15

The same log shows this disk being handled by Unassigned Devices:

unassigned.devices: Disk with ID 'ST8000DM004-2CX188_ZCT05AS7 (dev4)' is not set to auto mount.

So six weeks earlier, ZCT05AS7 was an unassigned/spare disk, not an array member. At some point afterward it was assigned to slot 15, and it later appeared as unmountable.

Not sure if this has been reported before where an unassigned disk get unexpectedly added to the array.

3 minutes ago, krh1009 said:

Update: the unmountable disk was not actually a long-time array member

Correction to my earlier posts. I had assumed the 8TB Seagate (ST8000DM004-2CX188_ZCT05AS7) had been Disk 15 for a long time before becoming unmountable. The logs show otherwise.

I checked syslog-previous from a flash backup about six weeks before the problem. At that time, slot 15 was empty:

mdcmd (17): import 15

The same log shows this disk being handled by Unassigned Devices:

unassigned.devices: Disk with ID 'ST8000DM004-2CX188_ZCT05AS7 (dev4)' is not set to auto mount.

So six weeks earlier, ZCT05AS7 was an unassigned/spare disk, not an array member. At some point afterward it was assigned to slot 15, and it later appeared as unmountable.

Not sure if this has been reported before where an unassigned disk get unexpectedly added to the array.

Never heard of an Unassigned Disk being added to the array without the User doing it manually. If it WAS done manually then I would expect it to show as unmountable until it was formatted after adding it to the array.