itimpi

Have you put the key file into the config folder on the flash drive?

Yes. At a point in the past the only bz* type files were bzroot and bzimage but as Unraid functionality has increased additional ones have been added which is probably where the confusion arises. If you always copy all bz* type files then you are good. As was mentioned any that are superfluous to a release are simply ignored.

This is perfectly normal Unraid will be emulating disk2 using the combination of all the good data drives plus parity. The data showing will be what will end up on disk2 after you have rebuilt it.

I missed that and it is virtually certain to be the problem with it being set to 1. This meant only the top level folder (the one corresponding to the share name) is allowed to be replicated across drives. Once a sub-folder is created on a drive then all subsequent files for that folder (or a sub-folder) will be constrained to that drive. in the event of contention between Allocation Method and Split Level for choosing a drive then Split Level always wins. You have various ways to proceed: Relax the Split Level setting to be less constrained. If you do not care which disk files end up on then you can set it to be unconstrained. If not then a value appropriate to your chosen strategy needs to be used. Manually move files from the full drive to another one to free up room on disk1 . There are a variety of ways to achieve this such as the built-in Midnight Commander (mc) CLI tool; the unBalance plugin; graphical docker containers such as Krusader or Dolphin; across the network using your preferred file manager in your client OS. A combination of these is also possible depending in what strategy you want for spreading files across disks. If you give information in what you want to end up with we can give some advice.

That means you need disks drives that are larger than 20TB and although that may happen one day we are not there yet The setting is the amount of free space on a drive that will tell Unraid it should stop trying to use it if it falls below that value. Did you perhaps mean to set it to 20GB?

This does not really make sense as Unraid does not support Users in the traditional sense - only for access via shares. The whole of the GUI is only accessible to the ‘root’ user and used for admin purposes and changing that basic assumption would be a fundamental rework.

Looking at those reports disk2 looks fine. CRC errors are connection errors and are almost always due to factors external to the drive such as the SATA or power cabling.

What exactly do you mean by this? Disk2 should have come back by itself (albeit disabled) and I am a bit worried that you have taken an action that might mean its contents will be lost. you should provide new diagnostics so that we can see what the current state of the system is.

Start by setting the Minimum Free Space for the share to be larger than the largest file you expect to write to the share. What value do you have set for the Use Cache setting for the share? BTW: instead of posting the syslog you should post the system diagnostics zip file (obtained via Tools->Diagnostics) as it provides those trying to help far more information about how your system is configured (and includes the syslog anyway).

You probably have the VM network type to be virbr0 at the moment? If so you need to make sure you have enabled bridging under Settings->Network and then in the VM settings you have assigned the bridged connection (probably br0) as the network type instead of virbr0.

Unraid does not normally care how the disks are connected - it recognizes the disks by their serial numbers. The only time you might have any issues is when the controllers involved report the serial numbers in different formats.

Mine never seems to get to hot to touch so heat does not seem to be a problem for me. I am using a LSI 9201-16i card.

Unraid does not include any support for repairing Bit Rot. If you use BTRFS as the file system on a drive then this has built in support for detecting corruption. If you use XFS then you can install the File Integrity plugin to help detect this type of issue. In both cases it is assumed that you restore from your backups to correct such an issue. In practise with modern hardware Bit Rot is rare and there are many other ways to corrupt data that are nothing to do with Bit Rot and are more likely to happen. Unraid allows a share to span multiple drives as a standard feature. The only restriction is that an individual file has to fit on a single drive (this a by-product of the fact that each Unraid drive has a discrete file system that in emergencies can be read outside the Unraid array).

I applied the Red version; left it for about 10 minutes; used a cotton bud to clean off any excess left; applied the Gold version; left that for about 5 minutes; plugged the drive back in. If I have any reason to take the system apart I might do the SATA cables as well, and possibly even those inside the hot-swap cages.

I was using the Red version to 'clean' the contacts and then the Gold version to re-plate the contacts. I just did it to the drives (I have hot-swap cages), but I cannot see how using it on the other parts in the connection path can cause an issue as long as you are careful about it.