JorgeB

It's a kernel bug, it also affects Ubuntu with ZFS for example, until the issue is corrected you should not run kernel 5.15 or newer with vt-d enabled on that server.

Please post the complete diagnostics.

See if there's a support thread for that docker, much more likely to get help there:

Yep, that is OK.

Parity isn't giving a complete SMART report, so it does look like a device problem.

Probably best, I can't really help with those.

FCP no longer works in such an old release, but you can still update.

That doesn't sound right. Disk looks mostly OK, you can run a parity check or extended SMART test once the rebuild is done.

That's the most affected model, I would only recommend running v6.10.x if vt-d is disabled, if you need it enable stay on v6.9.2 for now.

Not a bad idea if you can do without it, though all indications so far are that Dell servers are not affected, also latest thinking is that tg3 NIC is not the problem, looks like just a big coincident all affected models having one.

Which HP server? Careful that some models can suffer data corruption if vt-d is enable with v6.10.x

You can change the eth assignments in the interface rules, set the main NIC as eth0: Reboot required to take effect.

You can use for example rsync over ssh, if you google that there will be lots of hits with various examples how to.

Looks like a link problem to me, but install latest stable release, delete/rename /boot/config/network.cfg, reboot and post new diags.

According to the last diags you posted the Intel NICs were being detected and initialized correctly, just no link is detected on either: Settings for eth4: Supported ports: [ FIBRE ] Link detected: no driver: ixgbe Settings for eth5: Supported ports: [ FIBRE ] Link detected: no driver: ixgbe This doesn't look like an Unraid issue to me, until a link is detected by the NICs they won't work.

That's completely unrelated, looks more like a board issue, also make sure you set the active NIC to eth0, if there are issues you can always delete/rename /boot/config/network.cfg to get back to default, with bonding enabled.

I wouldn't, I've seen similar issues before.

Just rebooting usually won't help, a power cycle might, though as mentioned I would recommend replacing or at least checking the cables first.

Jun 6 17:49:41 Tower kernel: ata4.00: disabled Disk dropped offline, this is usually a power/cable problem, before it dropped there are several ATA errors logged, same for the SSD, check/replace those cables and post new diags after array start.

Nope, sorry, bonienl might know.

Jun 7 09:44:11 sobnology smbd[2595]: [2022/06/07 09:44:11.445928, 0] ../../source3/smbd/service.c:787(make_connection_snum) Jun 7 09:44:11 sobnology smbd[2595]: make_connection_snum: canonicalize_connect_path failed for service Backup, path /mnt/user/Backup Jun 7 09:44:11 sobnology smbd[2595]: [2022/06/07 09:44:11.446657, 0] ../../source3/smbd/service.c:787(make_connection_snum) Jun 7 09:44:11 sobnology smbd[2595]: make_connection_snum: canonicalize_connect_path failed for service Downloads, path /mnt/user/Downloads I assume these are the two shares you lost access? I see the errors but not the reason for them. There's also still a lot of docker related log spam, you might want to try and find which docker is constantly doing this: Jun 7 09:49:43 sobnology kernel: docker0: port 1(veth85c9d7c) entered blocking state Jun 7 09:49:43 sobnology kernel: docker0: port 1(veth85c9d7c) entered disabled state Jun 7 09:49:43 sobnology kernel: device veth85c9d7c entered promiscuous mode Jun 7 09:49:43 sobnology kernel: docker0: port 1(veth85c9d7c) entered blocking state Jun 7 09:49:43 sobnology kernel: docker0: port 1(veth85c9d7c) entered forwarding state Jun 7 09:49:43 sobnology kernel: docker0: port 1(veth85c9d7c) entered disabled state Jun 7 09:49:44 sobnology kernel: eth0: renamed from veth84f21e4

You should the disable the Bluetooth module on the board BIOS, that's at least one of the things spamming the log.

Don't see anything strange with the network config, though you are using eth2 as the main NIC with bonding and there's no link on the other two NICs, just to rule out some issues with that I would suggest setting eth2 as eth0 and disabling bonding to see if it makes any difference.

There were write errors after the read errors, Unraid only disables a disk after a write error, in this case the disk dropped offline, hence why there's not SMART, check/replace cables/slot and post new diags after array start.