JorgeB

In this thread please:

If it really shuts down it might be hardware but enable the syslog server and post that after a crash.

Yes, if you have UD installed click on detach so it gets powered down first.

Set appdata to cache=prefer, disable docker service, run the mover.

You could have rebuilt both at the same time, just unassign parity, start array, stop array, reassign parity and start array to begin parity sync.

Assuming you are using v6 there's a bug with the latest release where autostart does not work if using a trial key, new release should be out soon with this fixed.

No need to format. Would need the diags after the the replacement attempt to see what's going on.

It's normal during the pool balance, nothing to worry about.

Request fio, if it's possible to make it work universally, there were some issues before due to different hardware, see: https://github.com/dmacias72/unRAID-NerdPack/issues/14#issuecomment-567564930

Running xfs_repair should fix all the corruptions, with no or some possible data loss, suggest first upgrading to v6.11.3 since it will have the latest xfsprogs, then check filesystem on all disks, run it without the -n option or nothing will be done.

OK, pool looks OK now, you can add the other NMVe device and also rebuild the disabled disk, just re-assign them to their correct slots and start the array, also suggest seeing here for better pool monitoring in case it drops again.

I don't see hoe a new config would cause filesystem corruption, are you using the same Unraid release you were on before?

Since the best indication we have for now is that high i/o with a docker container is causing this issue anyone willing try please test with fio running in a docker: -look for the debian-bullseye container by ich777 in apps -add one or more paths for the storage where the torrents usually go, e.g.: -after install open a terminal window to that container and type apt-get update apt-get -y install fio Fio is very flexible, you can do sequential and random write and read loads, for example for random reads and writes to a file: fio --filename=/x/test --size=100GB --direct=1 --rw=randrw --bs=4k --ioengine=libaio --iodepth=256 --runtime=1800 --numjobs=4 --time_based --group_reporting --name=iops-test-job --eta-newline=1 Some options than can be adjusted as you like: --filename= set the correct path/file name --size= file size used for testing --runtime= how long the test runs See here for other test examples, hopefully someone would find a test pattern that would reproduce this crash.

These 5 drive are connected to two Asmedia 2 port controllers, it can be one controller with two chips: [9:0:0:0] disk ATA WDC WD40EFRX-68N 0A82 /dev/sdf /dev/sg5 dir: /sys/bus/scsi/devices/9:0:0:0 [/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.2/0000:02:00.0/0000:03:00.0/ata9/host9/target9:0:0/9:0:0:0] [9:1:0:0] disk ATA ST8000VX004-2M11 AV01 /dev/sdg /dev/sg6 dir: /sys/bus/scsi/devices/9:1:0:0 [/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.2/0000:02:00.0/0000:03:00.0/ata9/host9/target9:1:0/9:1:0:0] [10:0:0:0] disk ATA ST8000VX004-2M11 AV01 /dev/sdh /dev/sg7 dir: /sys/bus/scsi/devices/10:0:0:0 [/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.2/0000:02:00.0/0000:03:00.0/ata10/host10/target10:0:0/10:0:0:0] [11:0:0:0] disk ATA ST4000NE001-2MA1 EN01 /dev/sdi /dev/sg8 dir: /sys/bus/scsi/devices/11:0:0:0 [/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.2/0000:02:06.0/0000:07:00.0/ata11/host11/target11:0:0/11:0:0:0] [12:0:0:0] disk ATA ST4000NE001-2MA1 EN01 /dev/sdj /dev/sg9 dir: /sys/bus/scsi/devices/12:0:0:0 [/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.2/0000:02:06.0/0000:07:00.0/ata12/host12/target12:0:0/12:0:0:0] sdf, sdg and sdh are connected to the same two port controller, and one of the ports is being shared by sdf and sdg, that's why both are ATA9.

You can then hide again if you want, or just edit.

For the not reachable issue need this. As for the controller, that link mentions Marvell, but you don't have any Marvell controller, I see two dual port Asmedia controllers, one of them with 3 disks connected, so there's a SATA multiplier in the controller or it's connected to an external enclosure using one, in either case those are not recommended, but most likely not the reason for the current issue.

I would try this and using a disk share for it.

That's strange but if you disable NIC bonding in network settings and set NIC A as eth0 it might help.

First lets try and fix the pool, looks like one the NVMe devices dropped offline in the past and it was never synced, stop the array, type: wipefs -a /dev/nvme0n1p1 then unassign both pool devices start array stop array reassign only the Sabrent NVMe start array post new diags.

Unraid disables a disk when there's a write error to it, it doesn't matter if the write error was caused by a bad disk or a bad cable, and most times it's a power or connection problem.

This assuming the rebuild finished, if it didn't like the screenshot shows you still need to finish it.

If there's data you can rebuild the disk again after updating to v6.11.3 and you won't lose any data, if there isn't you can just format the disk since it's much faster.

That was expected, just wanted to clear the log, you don't have parity assigned so the disk cannot be emulated, disk looks healthy so just go to Tools and do a new config, keep all assignments, then start array, disk should now mount, if it doesn't post new diags.

IRC it stays blue after the first array start, it should go to green next time you start it.

Enable the syslog server and post that after a crash.