JorgeB

Check filesystem on disk3.

Nothing special.

It's for the VMs, either the service was left enabled or another one already exists on cache.

Most likely. Run rsync -av /path/to/source/ /path/to/dest/ it will only copy any missing data.

Enable the syslog server and post that after a crash.

OK, I assumed disk9 mounted?

For dockers I recommend using the disk path, better for performance, with VMs like mentioned it should not make a difference, but it won't hurt.

You can also use /mnt/cache/appdata, assuming they are on cache.

Click on settings, then docker and VM Manager settings and disable both, then run the mover, bellow stop array button.

It's my understanding that with VMs /mnt/user is basically the same as /mnt/disk_share, but if that helps leave it as /mnt/cache,

You cannot check now since there are two invalid disks with single parity, so they cannot both be emulated, if you're not sure it's best to enable only disk4 and see if disk9 can be correctly emulated: -Tools -> New Config -> Retain current configuration: All -> Apply -Check all disks are assigned, assign any missing disk(s) if needed -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 disk9 -Start array (in normal mode now), ideally the emulated disk9 will now mount and contents look correct, if it doesn't you should run a filesystem check on the emulated disk -If the emulated disk mounts and contents look correct stop the array -Re-assign disk9 to rebuild and start array to begin.

Yeah, it was already reported, looks like it's still missing a module, it should be fixed for -rc6, but I'll post here when it's released.

Not seeing any errors after the scrub.

Firmware is a possibility, since the disk is pretty new, also you should do it anyway, so nothing to lose, if it doesn't help you can try other things, you can also try connecting the disk to the onboard SATA if it's available, that would also confirm if the disk/HBA combo is the problem.

What is the array problem? Please post the diagnostics.

Was anything written to disk9 after it got disabled?

I would start with replacing that, then you'll need to force enable disk4 to rebuild disk9, or re-enable both if nothing was written to disk9 after it got disabled.

System share has files on disk1, move them to cache, services must be disabled first.

Start here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

You are having issues with multiple apparently healthy disks, this suggests a power/controller/cable problem, do disks 3, 4 and 9 share anything in common, like a miniSAS cable or power splitter?

It's an option in the Unraid boot menu.

Try testdisk in Windows.

Upgrading the LSI firmware is easy and pretty safe.

There are PCIe errors affecting multiple devices Sep 18 15:12:49 TheVault kernel: xhci_hcd 0000:01:00.0: AER: can't recover (no error_detected callback) Sep 18 15:12:49 TheVault kernel: ahci 0000:01:00.1: AER: can't recover (no error_detected callback) Sep 18 15:12:49 TheVault kernel: pci 0000:03:00.0: AER: can't recover (no error_detected callback) Sep 18 15:12:49 TheVault kernel: igb 0000:05:00.0 eth0: PCIe link lost Then Sep 18 15:13:30 TheVault kernel: ahci 0000:01:00.1: AHCI controller unavailable! Look for a BIOS update, you can also try updating to v6.11.0-rc5, newer kernel might help.

Not with the default write mode, assuming there are no controllers bottlenecks you can get much better write speeds with turbo write, at the expense of all disks spinning up for any write, note that you have a disable disk, need to rebuild it first for turbo write to work correctly.