JorgeB

Diags are after rebooting so we can't see what happened, SMART looks mostly fine for both disks.

Yes, but a new config should fix that, no rebuild needed.

Do you mean those disks din't mount due to invalid partition layout? I would assume just removing the interposers wouldn't cause an issue other than the name change.

OK, didn't look at everything initially, you have a second HBA, there won't be an issue with the disks connected there and also those on the onboard SATA controller, the disks on the NetApp will have their name changed, so a new config will be required.

Not only not needed but it will prevent some functionalities, you'll need to move the disks a little back without them, never used NetApp enclosures but there should be holes in the caddy for that. If the the devices name change you'll need to go to Tools -> New config, reassign all the disks in their original positions, check "parity is already valid" and start the array.

On a second look, they might not change, you'll need to try.

Forgot to mention, besides not being able to run SMART tests it's also not possible to get drive temps and SMART attributes without removing them.

Disks are been seen as SAS: === START OF INFORMATION SECTION === Vendor: ST8000DM Transport protocol: SAS (SPL-3) Interposers are the little board at the back of the caddys: If you remove this the disks will been seen as SATA, note that doing this will require doing a new config in Unraid since all the devices names will change.

Please post the diagnostics.

If you're using SATA disks with interposeres remove them and they will be seen as regular SATA devices, assuming a true HBA is being used.

Disks changed name because they were moved from the RAID controller, also because of that they fail to mount in the array due to not conforming to the partition layout Unraid requires, that's two of the reasons we don't recommend RAID controllers, you have two options, assuming parity is still valid you can rebuild one disk at at time so that the correct partition layout can be recreated, like this: https://forums.unraid.net/topic/84717-moving-drives-from-non-hba-raid-card-to-hba/ Other option is to mount the disks with UD since it won't care about the incorrect partition layout and copy the data to new disks in the array.

There appear to be 3 failing disks with single parity, so some some data loss is expected, disk2 is failing for sure, disk1 might also be, run an extended SMART test on disks 1 and 3 and post new diags once they are done.

You should also disable NVMe RAID in case that's why no SATA controller being detected, and it will allow the NVMe device to also be detected.

RAID is enable for NVMe devices, curiously no Intel SATA controller is being detected by Linux, only a two port Asmedia controller, which I assume are these ports: Any disks connected there should work.

Most likely it will affect, like this:

With WD disks it's good practice to monitor these attributes: 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 997 200 Multi_Zone_Error_Rate ---R-- 100 253 000 - 0 A non zero value is never a good sign, especially if it keeps climbing, this one is from the failed disk, other ones are still at 0, so they should be good for now.

Yes. Wait for the extended test results, but if they just did a parity check they should be OK for now.

It's logged as a disk issue and the SMART test failed, so yes, the disk needs to be replaced.

They should.

Yes, that's for the internal docker network.

I believe this happened before, toggle to speed instead, that should still show and it's much more useful.

Also the docker image is corrupt, delete and re-create.

Feb 22 18:33:49 MOORETOWER kernel: macvlan_broadcast+0x10e/0x13c [macvlan] Feb 22 18:33:49 MOORETOWER kernel: macvlan_process_broadcast+0xf8/0x143 [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 and switching to ipvlan might fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info. https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

No, test the HBA in a different PC/Server, if available, to see if it's initialized correctly.

Feb 23 11:33:13 Big-Plex kernel: megaraid_sas 0000:01:00.0: Failed to init firmware Feb 23 11:33:13 Big-Plex kernel: megaraid_sas 0000:01:00.0: Failed from megasas_init_fw 6406 RAID controller is failing to initialize, test in another PC if available to confirm if it's board related or not.