Kilrah

The default is high-water, if a share is set to say split between disk1 and disk2 it'll start writing on disk2 once free space on disk1 is less than half the free space of disk2.
So looking at that screenshot if it was the case above it'd start writing on disk2 pretty soon, seems normal. 

du shows TiB, GUI shows TB. 36TiB=39.5TB.

You likely had a short power dip, was enough to knock out the server and router but not the console.

Since it needs a whole stack of containers you're probably best adapting the provided docker-compose in the Compose plugin. 

Unassign the drives, install the Unassigned Devices and Unassigned Devices Plus plugins, enable destructive mode in settings. You'll now get a red cross at the right of the drive names, click on that to erase all partitions on the disks you want to clear. They'll now be blank and ready for setting up however you want.

You can do a New Config, assign both drives, start the array with "Parity is already valid", then start a parity check without "Write corrections to parity" checked, and look at the number of errors. If it climbs like crazy stop the operation and array, new config again, swap the 2 drive assignments, do the same... If either of these goes with no parity errors you're most likely good. If not you'll have no choice but to rebuild parity.
 
Do note that for parity2 to be valid all data drives need to be assigned to the same slots as before too. 

Most likely. That's how SMR drives behave, if you fill their cache and continue writing they slow down to a crawl as they start thrashing trying to both flush cache AND accept new data at the same time. Pretty easy to see, if you pause the transfer and give them a couple of hours to flush internal cache, restart and it's normal for a while again that's your problem. 

Not at all, you can always shut down via short button press, and put the USB drive in another machine to change/delete config/ident.cfg.
 
 

Minimum RAM for current Unraid is 4GB.
 
Also it seems these drives are SMR, usually Seagate ones behave decently in sequential writes but that could also be a cause.

When did the notification first appear? If it was while building parity that's normal as the array is considered "failed" until it's fully protected again. 

Docker on Windows basically spins up a Linux virtual machine and runs in there so I believe it shouldn't be an issue, at most you have minor issues with line endings in files but that's easily dealt with with an editor like notepad++ that supports unix line endings.

Well without knowing what you did we can't be sure hence asking for what instructions you followed, but the reddit thread for example talks of running 
docker run cloudflare/cloudflared:2022.5.3 tunnel --no-autoupdate run --token <your token> which are generic instructions, and would have the result of creating a container that unraid has no idea about and has a random name since none was specified just like you see.
 
The first comment mentions that and not being clean in the unraid context (as you see) and says how to enter it using Add Container instead so unraid can track it.
 

OVA seems somewhat broken, get the iso and install clean instead?
 
 

You don't have enough RAM for an in-place update, minimum 4GB is now required (and recommended for Unraid in general). You need to do a manual update of the flash drive on another machine.

Probably need more detail but any variable should be set in the docker-compose file, no point trying to set it somewhere else as it would be overridden anyway. Docker image is unrelated.

Update unraid, 6.11.2 has a bug with formatting.

Run it in Docker:
https://hub.docker.com/r/networkstatic/iperf3
 
EDIT: Will be available in Apps in about an hour.
 
 

Since a directory can't be executable the x bit is unneeded, and reused to allow/prevent access to the contents.
https://unix.stackexchange.com/a/21252
 
So while files are fine at 644 directories need the x bit set. 

That's a configurable setting,
 

It will be worst for write performance. It would be better in the case of "reading a file from a disk while writing to another" you mention. 
On unraid writes are slow, hence the setup of using a cache SSD stuff gets written to, that you set to get moved to the array on a schedule in the middle of the night or other appropriate time where you're unlikely to be accessing the array.
 
  
Depends on which write mode you are, if you're in "reconstruct write" mode then writes to the array will happen at the speed of your slowest drive in the whole array, in read-modify-write it'll be less than half of the slowest between the drive that's being written to and the parity drive. 
 

Make sure your DNS/network on unraid are NOT set to use something like PiHole running on unraid itself. 

If you have a folder named "EFI-" on the drive rename it to "EFI".
Modern boards won't have legacy boot enabled by default anymore.
 
Alternatively you can enable CSM in the BIOS.

Was your nextcloud up to date, 2FA enabled etc?

Try adding only disk2, starting the array, formatting the drive, stopping again, then adding the parity drive as a 2nd step.