JorgeB

Run it again without -n or nothing will be done, if it asks for it use -L.

At what position is the check? Disk 4 is showing one or more slow zones in the beginning.

In the syslog it's log as the disk problem, but since the SMART test passed you can rebuild on top, make sure the emulated disk is still mounting before doing it, also a good idea to swap/replace cables before to rule them out if it happens again to the same disk.
 
There are also what look like connection issues with both cache devices, though strange that it's with both, unless they share a power splitter or something.

El disco se puede identificar por el número de serie.

It is, if you used it before it's now using the fist 15 day extension. 

Yes, and that's from the UD plugin, not Unraid.

Some strange crashing going on that might be affecting that, please reboot it the disks still don't mount post new diags.

Aug 30 04:40:02 Tower kernel: FAT-fs (sda1): Directory bread(block 537257) failed Aug 30 04:40:02 Tower kernel: FAT-fs (sda1): Directory bread(block 537258) failed Aug 30 04:40:02 Tower kernel: FAT-fs (sda1): Directory bread(block 537259) failed Aug 30 04:40:02 Tower kernel: FAT-fs (sda1): Directory bread(block 537260) failed Aug 30 04:40:02 Tower kernel: FAT-fs (sda1): Directory bread(block 537261) failed  
Flash drive problems, you can try backup and reformatting it, also make sure it's using a USB 2.0 port, if issues continue replace it.

Try updating to v6.11.0-rc4, if that doesn't help and IIRC a user with a similar error KVM error fixed it by creating as new identical VM, i.e., it was something in that specif VM.

This is a known issue that will happen when you have a single array device formatted with btrfs, parity will have an invalid btrfs filesystem that causes issues during btrfs device scan for the pools, solution for now would be to format disk5 with xfs like the remaining devices or if you really want btrfs for that device you can use encrypted btrfs.

Those are normal if you want to keep using the S3 sleep plugin, it's from the controllers waking up.

You can also get the diags in the console, see the link above for how to, but if all is well now it doesn't matter, get them if it happens again.

Type
mover stop and reboot, should fix the NFS issue.

This is a board issue, since it's posting in safe mode first thing to try is to reset the BIOS to defaults.

LSI is flashed to raid mode, you should flash it to IT mode, note that it will require a new config because all drives identification will change.

Check this and also update to v6.10.3, if it keeps happening after that enable the syslog server and post that after a crash.

UD requires the disks to have a partition, e.g., /dev/sdx1, disks without a partition cannot be mounted by UD, you can still mount them manually.
 
P.S: there's an existing support thread for the plugin, in the future please use that.

VM configuration/settings would revert, if there were any changes since, any data in the vdisks would remain.
 
 
 
 

This is usually the easiest way, and it also allows to keep docker/VMs online, if they are using cache.

According to the manual the slot is not shared, look for a BIOS update, it that doesn't help IMHO the best bet would be a different board (or controller).

That's from mcelog, not Unraid, you can ignore, fixed for v6.11.

No need to disable the pool, just change the use cache setting for that share to 'no', then change it back.

Are the shares being exported? Currently Unraid defaults to no (Share -> SMA Security Settings)

Aug 12 17:17:38 homeserver kernel: ixgbe 0000:05:00.1 eth1: NIC Link is Down Aug 12 17:17:38 homeserver kernel: bond0: (slave eth1): link status definitely down, disabling slave Aug 12 17:17:38 homeserver kernel: ixgbe 0000:05:00.1 eth1: NIC Link is Up 10 Gbps, Flow Control: None Aug 12 17:17:38 homeserver kernel: ixgbe 0000:05:00.1 eth1: NIC Link is Down  
This is filling up the log.
 
 

There's some unallocated space and it should be enough.