itimpi

I would think the most likely things to cause a reboot would be thermal (e.g. CPU overheating), or PSU issues.

The disk assignments have always been held in the super.dat file in the backup.   This is a binary file and thus not human readable.   Not sure when/how the disk_assignments .txt file gets created.

The parity check checks all of the parity disk as being correct.  Since your parity drive is larger than your biggest data drive it is checking that the remaining part of the parity disk is all zeroes.

Do you have “turbo Write” mode enabled?   If not then I expect the initial burst of speed happens while data is being cached to RAM and then the 30-50 MBps speed that continue is not atypical when writing to a parity protected array.  This section of the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page describes what is going on.   The Unraid OS->Manual section in particular covers most features of the current Unraid release.

There should be only 1 key file (presumably the Plus key as the last one that was valid).

You need to have two different shares if you want them to be treated differently by mover

Not sure what you mean?  Nginx is built into Unraid as it runs the webGUI.

At any point in time the parity check speed will be determined primarily  by the slowest drive currently involved.  The first 4TB would be no faster.    Once you get past the size of the data drives I would expect it to speed up dramatically

I think that the spindown on a SSD often just puts it into a lower power state.

If you want to continue using macvlan make sure that bridging is disabled on eth0 (as mentioned in Release notes).

The color coding just looks for certain strings in the log entries.    I am guessing that ‘checksum’ and ‘error’ are strings being looked for.    The lines look like perfectly normal information messages.
 
i notice that you are using macvlan networking for docker.   If you experience instability you might want to consider switching to ipvlan as mentioned in the Release Notes.

You need to follow the instructions in the provided links to recreate your docker.img file and reload the containers via Apps->Previous Apps. 

it looks like you are getting macvlan crashes, and these are known to eventually crash the server on the 6.12.x Unraid releases. The easiest thing is to switch docker to using ipvlan networking. If you need to continue using macvlan then make sure you disable bridging on eth0 as mentioned in the release notes.
 

Do you use power splitters to get the power to the drives?    I have found these can often cause problems.

You might find this section of the online documentation accessible via the Manual link at the bottom of the Unraid GUI to be of use.   In addition every forum page has a DOCS link at the top and a Documentation link at the bottom.   The Unraid OS->Manual section covers most aspects of the current Unraid release.

You seem to be getting macvlan related crashes.  These are known to eventually crash the server.  Switching docker to using ipvlan is the easiest fix.

If you want a share to be visible over the network then you need to change the Export setting under SMB to something other than the default of No.   which value you select depends on your security needs.

Linux is case sensitive for folder/file names whereas SMB is not.   Therefore if you have two folders at the Linux level with the same spelling but different case then only one of them will get picked up by the share with the same spelling.

If you now have the basic .key file in the config folder on the flash drive, then I think you need to reboot to activate it.  

Have you stopped the array first?

I would expect the VM to regularily be reading/writing to its virtual disk so that is likely the cause of your symptoms.

He must have at least one disk in the main array as this is a requirement with the current Unraid release (although this is expected to be removed in a future release).  Perhaps he simply has the main array with XFS format disks (which is the default).  In your case it could be something like a small flash drive if you do not want to store anything on it.

Not sure where you got this information from as it definitely is possible.
 
Moving share files from the array to a pool is covered here in 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.   The Unraid OS->Manual section covers most aspects of the current Unraid release.

That call trace looks like it could be macvlan related.   If so you need to either switch docker to using ipvlan, or alternatively disable bridging on eth0 to continue using macvlan.

Your parity2 disk is only 6TB so cannot add array drives larger than that until that drive has been upgraded to a larger size.  You can never add array drives that are larger than the smallest parity drive..

Your system seems to be experiencing Macvlan related crashes which are known to eventually crash the server.   As mentioned in the release notes you should either switch docker to using ipvlan, or if you want to continue using Macvlan make sure that Bridging is disabled for eth0.