JorgeB

Oct 5 10:07:21 ChrizNAS kernel: FAT-fs (sda1): error, corrupted directory (invalid entries) Connect the flash drive to a PC and run chkdsk.

Yes, replacement disk would need to be smaller.

That's a known issue with servers using a Matrox GPU, it will be fixed for v6.11.1, if you want for now you can downgrade to v6.10.3, it works there.

Don't know, you can try.

You can do one to confirm all is OK.

Link detected: no Until the NICs detect a link they won't work, you can boot using the GUI mode, it might help to ckeck/set the lan config.

That's a BIOS problem, not much you can do then.

Possibly unrelated but I'm seeing some call traces that should be gone if you switch to ipvlan (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right))

Enable the syslog server and post that after a crash together with the complete diagnostics.

You can do a new config and re-assign all the disks (Tools -> New config)

No link is being detected on any of your NICs, check cables/connections.

Oct 2 11:29:43 vildkatt kernel: md: recovery thread: P corrected, sector=1064 Oct 2 11:29:43 vildkatt kernel: md: recovery thread: P corrected, sector=13304 Oct 2 11:29:43 vildkatt kernel: md: recovery thread: P corrected, sector=30712 Oct 2 11:29:43 vildkatt kernel: md: recovery thread: P corrected, sector=44016 Oct 2 11:29:43 vildkatt kernel: md: recovery thread: P corrected, sector=58344 Oct 2 11:29:43 vildkatt kernel: md: recovery thread: P corrected, sector=69616 Oct 2 11:29:43 vildkatt kernel: md: recovery thread: P corrected, sector=81896 Oct 2 11:29:43 vildkatt kernel: md: recovery thread: P corrected, sector=92136 Oct 2 11:29:43 vildkatt kernel: md: recovery thread: P corrected, sector=103400 Oct 4 20:40:57 vildkatt kernel: md: recovery thread: P incorrect, sector=1064 Oct 4 20:40:57 vildkatt kernel: md: recovery thread: P incorrect, sector=13304 Oct 4 20:40:57 vildkatt kernel: md: recovery thread: P incorrect, sector=30712 Oct 4 20:40:57 vildkatt kernel: md: recovery thread: P incorrect, sector=44016 Oct 4 20:40:57 vildkatt kernel: md: recovery thread: P incorrect, sector=58344 Oct 4 20:40:57 vildkatt kernel: md: recovery thread: P incorrect, sector=69616 Oct 4 20:40:57 vildkatt kernel: md: recovery thread: P incorrect, sector=81896 Oct 4 20:40:57 vildkatt kernel: md: recovery thread: P incorrect, sector=92136 Oct 4 20:40:57 vildkatt kernel: md: recovery thread: P incorrect, sector=103400 Didn't check them all but at least the first ones are exactly the same sectors as before, that could indicate that they were previously wrongly updated, due to some hardware issue, run a correcting check and then a non correcting one right after.

Disk3 is SMR, so it's normal to suffer lower write speeds every few minutes, does it get better if you temporarilly transfer just to the other disks?

By your description parity should still be mostly valid, but at leas with the new one it's not, you can try repeating the procedure with the old parity.

Did you see the link above? https://forums.unraid.net/topic/76066-vm-settings-change-stuck-at-updating/?do=findComment&comment=705420

That's because they are being detected with different names, and Unraid does not accept that, one of the reasons we don't recommend using USB enclosures.

It it still going slow or did it speed up after the 8TB mark? Possibly you have a disk with slow sectors, diskspeed docker might show something.

That disk doesn't look very healthy: Elements in grown defect list: 2812 You should replace it.

No valid filesystem in being detected on the emulated disk1, that suggests parity is not valid, are you sing new or old parity?

-Tools -> New Config -> Retain current configuration: All -> Apply -Check all assignments and assign any missing disk(s) if needed, including cloned disk3 and the new disk4, replacement disk should be same size or larger than the old one -IMPORTANT - Check both "parity is already valid" and "maintenance mode" and start the array (note that the GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the checkbox, but it won't be as long as it's checked) -Stop array -Unassign disk4 -Start array (in normal mode now), ideally the emulated disk will now mount and contents look correct. -Grab and post new diags.

Emulated disk mounted, assuming contents look correct you can rebuild on top.

On that screenshot they are showing as missing, not wrong, as in they are not being detected.

Look for a BIOS update.

Try booting in safe mode.

Start by checking cooler and temps, that looks like an overheating CPU.