JorgeB

There was a bug with this, possibly not yet totally solved, you can edit the settings file manually:

Connect the old disk back, then go to Tools -> New Config -> Retain current configuration: All -> Apply Back in the main page assign the old disk, unassign disk7, you can leave that slot unused or assign a new disk there if you want, remaining disks should already be correctly assigned, check all is well and start the array to begin a parity sync.

This usually the indication of a hardware issue, or hardware that is not working with Unraid, do you have a different PC (or board + CPU) you could try with? Data should still be all there.

Assuming the disk was good data on that disk is 100% recoverable, data on the disk7 on the other hand could be lost, there's a chance of recovery by getting the old disk there and force a rebuild of disk7, but this would only work if the data on the array is 100% unchanged since you tried the rebuild, and even so there's a chance of some filesystem corruption since parity with the old disk won't be 100% valid due to mounting the other disks.

Other than testing with anther switch, or another NIC on that switch no much more I can think of.

You have 3 invalid disks, dual parity can only have 2, assuming the actual disable disk is fine since it looks healthy do a new config and re-sync parity, this should take care of the unmountable disk1, still seeing a lot of NMI events in the log though, you'll then need to check filesystem on disk2.

Please post current diags.

Unfortunately there's nothing logged about the crash, this usually points to a hardware problem, one more thing you can try it to boot the server in safe mode with all docker/VMs disable, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

OK, do you still have the old drive you were replacing intact?

For #1 see here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

Fix filesystem on disk7, then try again, with the array in maintenance mode: xfs_repair -v /dev/md7 If it asks for -L use it.

Syslog is spammed with mover entries and it's missing all info after that, reboot and if it's still a problem post new diags.

Post current diags.

Not unless you're going to be using SSDs or a SAS expander with more than the 8 devices.

Yes.

Yep, there were write errors on parity before the rebuild even begun: Apr 9 15:28:31 NAS1 kernel: md: disk0 write error, sector=1953567832 Apr 9 15:28:31 NAS1 kernel: md: disk0 write error, sector=1953567840 Apr 9 15:28:31 NAS1 kernel: md: disk0 write error, sector=1953567848 So parity got disabled and the rebuild would be 100% corrupt: Apr 9 15:28:40 NAS1 kernel: md: recovery thread: recon D12 ... Apr 9 15:28:40 NAS1 kernel: md: recovery thread: multiple disk errors, sector=8 Apr 9 15:28:40 NAS1 kernel: md: recovery thread: multiple disk errors, sector=16 etc Not clear to me how parity is enable again and disk12 disable in the 1st diags you posted, or are they old diags? If not, what happened after this:

Nope, click the + sign, it's below that, e.g.: Note that you can change name before mounting the disk by clicking on it.

@dlandonLooks like you need to make the timeout for this longer. Yep, you can use for example: rsync -av /mnt/disks/name_of_UD_disk/ /mnt/diskX/ Replace X with correct disk number.

Try manually: xfs_admin -U generate /dev/sdd1

use -L

See here then post that log after a crash.

Run xfs_repair first: xfs_repair -v /dev/sdd1

Change that filesystem's UUID (Settings -> Unassigned devices) then you can have the array started together with that disk and compare both disks content, you can for example use rsync.

Like mentioned there you can try -vi to ignore the errors.

Please post the diagnostics: Tools -> Diagnostics