itimpi

There is this in the syslog:
Nov 20 22:30:06 unraid emhttpd: error: shfs_mk_share, 6455: No space left on device (28): ioctl: /backups Make sure when trying to setup the share you specify a value for Minimum Free Space that is less than you have available on one of your drives.    I think it now defaults to 10% and your drives are all over 90% full.

Yes when it runs out of space to expand.
 
It can often be better to simply pass thru the physical disk to a VM rather than using a vdisk if you want the whole space available to be used by the VM.

The instructions are not quite valid for recent Unraid releases.  As you found there will be issues stopping the array and doing a clean shutdown.
 
You also have do do something to tell Unraid that the drive you want to remove is no longer being used.  What you could probably do at this stage is:
Use Tools>New Config with the option to keep all assignments. Return to the Main tab and unassign the disk to be removed. Tick the Parity is already valid checkbox Start the array to commit the new assignments At this point it might be worth doing a parity check in case you made a mistake in any of the earlier steps and parity was not actually completely valid.

You can do this if you have the Dynamix File Manager plugin installed.

You can do both at the same time if you have dual parity.    I assume that parity1 is already a 12TB (or larger) disk?

A server powering itself off is almost certainly hardware related and will show nothing in the logs.   Since you mention it happening when the CPU is particularly active it could be due to the CPU overheating and causing a thermal shutdown so could be worth checking cooling.

A disk gets disabled if a write to it fails.   When that happens Unraid will start emulating its contents (and stops using the physical drive) using the combination of parity plus the other drives.
 
To clear this status you have to rebuild the drive as described in this section of the online documentation accessible via the Manual link at the bottom of the Unraid GUI (in addition every forum page has a DOCS link at the top and a Documentation link at the bottom) and the Unraid OS->Manual section covers most aspects of the current Unraid release.   Since it looks like the emulation is showing all the disk contents then you can use the option to rebuild the drive onto itself.

Yes you will need to use New Config to remove the drive and then rebuild parity.  Since you are rebuilding parity anyway you can add the parity2 disk at the same time.

Once a drive has been disabled (as indicated by the red ‘x’) this will be because a write to it failed so Unraid will start ‘emulating’ it.   You need to rebuild the drive to clear this status.    According to the diagnostics it looks like the emulated disk is mounting fine so you can  Rebuild the drive to itself.

You can delete the sharename.cfg file from the config/shares folder on the flash drive and it will then get recreated with default values.    This will not touch the data on the drives.

The only sensible way I see for these to be used in the current releases would be to use them as Unassigned Devices.   However that does have the disadvantage that they cannot be part of any User Shares.
 
Note that if you want to set up a pool and be able to easily add disks in the future then you could use BTRFS for this.   That format allows adding drives at any time and of mismatched sizes.    However a possible downside is it may not be as good at recovering from drive issues as ZFS of XFS.
 
As was mentioned eventually Unraid 7 should support your desired Use Case but I would think that is still some way off - I would guess at it being the Unraid 7.1 release although I have no inside information around tis.

My suggestion was to simply delete the sharename.cfg type files for the problem shares from the config/shares folder on the flash drive to cause Unraid to recreate them with default values.    Easiest way to do this is to use the Dynamix File Manager by clicking on the leftmost icon on the Boot device on the main tab.    You can also use that to (optionally) look at the current content of the files as they are text files.

It definitely looks like you have corruption in your docker.img file:
Nov 3 04:16:03 Server kernel: BTRFS warning (device loop2): csum failed root 5 ino 5476243 off 0 csum 0xf34e21bd expected csum 0x46e26f17 mirror 1 Nov 3 04:16:03 Server kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 252, rd 0, flush 0, corrupt 240274, gen 0 Nov 3 04:16:03 Server kernel: BTRFS warning (device loop2): csum failed root 5 ino 5476243 off 4096 csum 0x9ccb8b17 expected csum 0xf603cbd7 mirror 1 Nov 3 04:16:03 Server kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 252, rd 0, flush 0, corrupt 240275, gen 0 Nov 3 04:16:03 Server kernel: BTRFS warning (device loop2): csum failed root 5 ino 5476243 off 0 csum 0xf34e21bd expected csum 0x46e26f17 mirror 1 Nov 3 04:16:03 Server kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 252, rd 0, flush 0, corrupt 240276, gen 0
I would suggest that you start by doing the following:
running a scrub on the cache pool to see if it says its file system is corrupt. running a memtest as RAM issues are a common cause of btrfs issues. at the very least you are then going to need to recreate the docket.img file and then reinstall your docker containers via Apps->Previous Apps (to get them with settings intact).
 

Do you have the Mover Tuning plugin installed?  This often seems to interfere with standard mover behaviour.
 
If it is not that then I suggest you make sure Mover logging is enabled - repeat the problem and then take diagnostics and add them to your next post in this thread.

You can do this via the New Config tool.    Note that you will have to rebuild parity1 based on the drives that are being retained if you are going to retain single parity.  The old parity drive(s) will show up as an unformatted drive that will need formatting after you start the array with it assigned as data drives.

The share anonymised as ‘D———-a’ is on the cache and set to remain there.   Is that the one taking up space.
 
you could try going to the Shares tab and clicking the Compute All button to see how much space each share is using on the drives.

Change the settings for the Cache Dirs plugin to only include shares you still have.

In theory reallocated sectors are do not in themselves indicate a problem as long as they remain stable.    However if they start increasing then that is a good indication that the disk is likely to fail soon.

If using splitters you should make sure that a SATA connector is not split more than 2 ways.   With Molex connectors (which are more robust) you can normally split these 4 ways without issues.

No - Cleared (every sector set to all zeroes).  A disk has to be all zeroes before it can be added as an array drive without affecting parity.   Formatting happens after the add has succeeded.   Unraid does the Clear automatically when it is needed.

This is not possible as parity is updated in real time as you change data on the array.
 
The monthly task you mention is NOT a synchronization task - it is a health check that parity is currently valid for the data on the main array.
 

1.  Really up to you.  Not sure that there is any specific reason above how you want to control your data replacement.
2.  Only reason is that often users forget they have set something at the global level and wonder why a disk they then add does not get used.
3.  Not relevant to rebuilds as parity has no data, and the rebuild works at the disk sector level and has no idea of the meaning of the contents of any sector.

That is the way to go.   
 
By default that would rebuild parity but there is an option to suppress that if you are reasonably certain that parity is correct.  However if you use that option it would be a good idea to relatively soon carry out a parity check to make sure that parity WAS (at least mostly)  valid.

You could use something like NextCloud for this I would think.

Which option would better suit your needs really boils down to whether some extra space is likely to be useful.
 
With option 2 you would normally use the New Config tool to remove disk2 which then means you have to rebuild parity (and potentially move disk3 into the disk2 slot in the GUI at the same time) so do not forget that step.
 
With option 1 there is no reason not to keep disk2 as an emergency spare as you say it is currently exhibiting no sign of problems.   A variant on option 1 would be to keep disk2 in the array and keep the old 4TB parity drive as a spare for failures in disk2 or disk3.