JorgeB

If it's a board problem it likely won't help, but possibly worth a try, it helps in some similar cases, on the main GUI page click on the flash drive, scroll down to "Syslinux Configuration", make sure it's set to "menu view" (top right) and add this to your default boot option, after "append initrd=/bzroot" nvme_core.default_ps_max_latency_us=0 pcie_aspm=off e.g.: append initrd=/bzroot nvme_core.default_ps_max_latency_us=0 pcie_aspm=off Note that you will likely need to power cycle the server to get the device back, just rebooting it's usually not enough, then see if the above makes a difference.

dm-5 is this UD disk, not the flash drive: Sep 20 08:30:27 smartserver kernel: XFS (dm-5): Mounting V5 Filesystem Sep 20 08:30:27 smartserver kernel: XFS (dm-5): Ending clean mount Sep 20 08:30:27 smartserver kernel: xfs filesystem being mounted at /mnt/disks/WD_Elements_25A3

Sep 26 07:33:43 unraid1 kernel: device eth0 entered promiscuous mode Sep 26 07:33:44 unraid1 kernel: device eth0 left promiscuous mode Sep 26 07:36:24 unraid1 kernel: device eth0 entered promiscuous mode Sep 26 07:36:35 unraid1 kernel: device eth0 left promiscuous mode Sep 26 07:36:35 unraid1 kernel: device eth0 entered promiscuous mode Sep 26 07:36:36 unraid1 kernel: device eth0 left promiscuous mode Sep 26 07:36:36 unraid1 kernel: device eth0 entered promiscuous mode This is likely not the problem but it's spamming the log, see if you have a container constantly restarting, you can check the uptimes.

Parity dropped offline, most likely a power/connection problem, syslog shows some random call traces and segfaults, start by running memtest, also check this.

Logs are being spammed with USB errors, see if you can fix that, very difficult to analyze them like that. Also one of the NVMe devices dropped offline: Sep 2 04:40:02 NAS kernel: BTRFS error (device nvme0n1p1): bdev /dev/nvme0n1p1 errs: wr 31975314, rd 229095, flush 455696, corrupt 0, gen 0

So if I understand, one of the unmountable disks was parity and the other ones are new, and don't have any data? If that's correct you won't be able to find out which one was parity, just assign one of the unmountable 8TB disks as parity, the other ones as data and re-sync parity.

The device dropped offline, the same thing would have happened with btrfs. Please post the complete diagnostics. Currently the GUI doesn't warn of pool device issues, xfs, btrfs or zfs, I have a very old feature request for this but for now see here for better pool monitoring for btrfs and zfs.

It could be.

Did you try this?

That's very strange, stop the array and see if the disks mounts manual (read-only) mkdir /x mount -v -t btrfs -o ro /dev/sdc1 /x If it mounts see if you can browse the data under /x to unmount then umount /x

If you're going to wait for the new HBA I think you should.

The filesystem looks OK.

Personally I would use btrfs or zfs, since they automatically checksum all data, for xfs you can use the File Integrity plugin, or an external tool like corz.

Looks good so far.

I like the Sandisk Cruzer Blade, one of the last USB 2.0 drives you can get. There is for an automated transfer, but you can contact support and they will do it for you.

The SQUASHFS errors usually mean a bad flash drive, you can try backup and re-formatting or just replacing it, also make sure it's using a USB 2.0 port.

Sep 26 08:02:18 unraid kernel: BTRFS warning (device sdf1): devid 2 uuid 82b09bec-fe6c-4de2-ad5a-dfe099da7925 is missing Sep 26 08:02:18 unraid kernel: BTRFS error (device sdf1): failed to read chunk root Sep 26 08:02:18 unraid kernel: BTRFS error (device sdf1): open_ctree failed This error suggest the pool was not redundant, at least not fully, you can try the recovery options here but most likely they also won't work without the missing device.

Enable the syslog server and post that after a crash.

Yes, check/replace/swap cables and see if it doesn't happen again, or if it does to a different disk of the same model.

The syslog in the diags is incomplete, enable the syslog server and post that after a crash.

Most likely needs this:

UD won't mount a degraded pool, assign the device back to a pool and post new diags after array start.

It's not logged as a disk problem and the disk looks healthy, could be a power/connection problem or an issue with the LSI, I've been seeing some issues with LSI SAS2 controllers and large capacity Seagate drives, but since you have more identical drives, if that's the only one causing issues it's more likely power/connection.

Reboot and post new diags after array start, but without a SMART report difficult to guess if it's a disk problem or not.

Looks more like a power/connection issue with parity, could also be this: https://forums.unraid.net/topic/103938-69x-lsi-controllers-ironwolf-disks-disabling-summary-fix/