I'm runinng Unraid 7.14, syslog and diagnostics attached. Only realised this morning but two drives have become disabled last night. From the syslog it looks like a power glitch (similar output I saw before from a loose cable); both drives are in the same cage. One drive is showing as 'disabled' with an x in 'main' and claiming to be emulated. The other one is still showing as enabled in 'Main', however it doesn't have a temperature reading, can't access SMART directly, can't spin it down with the button. Basically it's like it's disabled but without an x. This drive (disk 9) was streaming a file at the time, in the Syslog I've replaced the filename with [FILENAME]. I appear to be able to access data from the emulated drive; although I can see the filenames etc. on the second drive (disk9) I can't access them from Windows, it just errors out. - edited to add, i can access files on the emulated drive but they're gibberish, since presumably it can't get the data from disk9...

Both drives are showing in unassigned devices (I assume with new ID's); the diagnostics was able to access the SMART info from both and I can't see any problems. The data on both I think is very likely to be intact.

So I could power down the server, reseat the cables etc., and power it back up again. However I can't do a rebuild in place (this is what I did before when 1 drive had this problem), as two drives are disabled. Or since disk 9 doesn't seem to be marked as disabled, perhaps it will just work on powering back up. Or, can I in some fashion mark both of these drives as 'good', then just rebuild parity?. Or if some other procedure would be appropiate, any advice would be much appreciated.

Thanks,

tower-syslog-20251114-1844.zip tower-diagnostics-20251114-1848.zip

Edited November 14, 2025Nov 14 by Shamutanti
Updating information

Since there's only one parity, only one drive can be disabled, power down, check/replace the cables for both, and post new diags after array start.

Hi Jorge,

Array has restarted without problems; the second disk which was problematic (disk 9) is enabled and working in the array; disk 4 as expected still showing as disabled/emaulted. Neither showing in unassigned devices now. No obvious SMART problems for either (updated syslog and diags attached) ; only unusual thing my amateur eye can spot in the syslog is this bit :

ov 15 11:22:41 Tower emhttpd: shcmd (207): xfs_admin -U generate /dev/md4p1
Nov 15 11:22:41 Tower root: ERROR: The filesystem has valuable metadata changes in a log which needs to
Nov 15 11:22:41 Tower root: be replayed.  Mount the filesystem to replay the log, and unmount it before
Nov 15 11:22:41 Tower root: re-running xfs_admin.  If the filesystem is a snapshot of a mounted filesystem,
Nov 15 11:22:41 Tower root: you may need to give mount the nouuid option.  If you are unable to mount
Nov 15 11:22:41 Tower root: the filesystem, then use the xfs_repair -L option to destroy the log and
Nov 15 11:22:41 Tower root: attempt a repair.  Note that destroying the log may cause corruption --
Nov 15 11:22:41 Tower root: please attempt a mount of the filesystem before doing this.

So in theory I could just to a rebuild in place for disk 4 that is disabled; just slightly concerned in as much as at the moment I think all the data on the disk is intact, but if something goes wrong during a rebuild with another drive it might be lost....But if that's the right thing to do then I'll give it a go. - edited to add, I do have enough space on another drive that i could move all the data off this drive first. Although after that i don't know if doing a full rebuild for any empty drive would be worth it....

Thanks,

tower-diagnostics-20251115-1126.zip tower-syslog-20251115-1122.zip

Edited November 15, 2025Nov 15 by Shamutanti
further thoughts

You can ignore those xfs errors since the emulated disk is mounted, and as long as the contents look correct, you can rebuild on top, but I recommend checking/replacing cables first.

Thanks Jorge, I'll get some replacement cables in first (and move data off in the meantime)