itimpi

As far as I know that is expected behaviour.
 
The parity Check Tuning plugin gives you the option to automatically pause the array operation while mover is running so that mover runs at maximum speed and then resume the array operation when mover completes.

It is perfectly normal for the drive(s) holding the 'system' share in particular to get regular activity as that is where the docker sub-system constantly has files open all the time it is running (which was what would have kept disk1+parity constantly spun up when that share was on disk1.
 
In addition the same consideration applies to the 'appdata' share any time you have any container running which is configured to use it.
 
In summary from your description you are just seeing the normal activity generated by running docker containers.   The whole idea is to keep such writes from going to the main array both for performance reasons and to avoid keeping array disks spun up.

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted.  You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash.  The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field. 
 
However the syslog in the diagnostics you did post suggests you may have had macvlan crashes - these will eventually bring down the server.   The recommendation is to switch docker networking to use ipvlan which is more stable.  If you want to continue to use macvlan then make sure that bridging is disabled on eth0.
 
You also are loading a LOT of extras so any of them may be causing an issue - does the problem still occur if you boot in Safe Mode to stop plugins and extras from being loaded?
 

The \r indicates a carriage return that you have somehow appended to the name.   You need to get rid of that folder to tidy things up.   Not sure if Dynamix File Manager will be able to delete that folder or not. 

Nor possible.  Each drive in the main array is a free-standing file system.

Limetech have stated that all users who have one of the current Basic/Plus/Pro licences will be entitled to all future upgrades at no additional cost.  Covered in some detail in their blog on the subject.

With trial keys you have to reassign all the drives if you want to get the config on another drive.  This means do not copy the super.dat file in the config folder from the old flash drive to the new one.

If you want more control then use the Parity Check Tuning plugin to handle pauses and resumes.   You can tell that plugin whether Manual checks should be paused or not.

It looks like the Minimum Free Space setting for your share is less than the available space which is why you get told there is no space available.

You have something creating the ‘users’ folder under /mnt.    You need to identify what is doing this and correct it.

Yes - as long as all new checks keep reporting 0 errors.

There are continual messages along the lines of:
Mar 5 09:37:53 crookserver2 kernel: sd 1:0:5:0: attempting task abort!scmd(0x000000001af04f39), outstanding for 30416 ms & timeout 30000 ms Mar 5 09:37:53 crookserver2 kernel: sd 1:0:5:0: [sdg] tag#629 CDB: opcode=0x88 88 00 00 00 00 00 00 02 7f 80 00 00 04 00 00 00 Mar 5 09:37:53 crookserver2 kernel: scsi target1:0:5: handle(0x000d), sas_address(0x4433221105000000), phy(5) Mar 5 09:37:53 crookserver2 kernel: scsi target1:0:5: enclosure logical id(0x500605b003f99080), slot(6) Mar 5 09:37:53 crookserver2 kernel: sd 1:0:5:0: task abort: SUCCESS scmd(0x000000001af04f39) This implies there is either a problem with sdg (disk1) or with the hardware to which it is attached.

What type of SMART errors?    Some errors (e.g. CRC errors) can mean the disk itself is fine but there is an issue with the cabling or power.

Just a thought - are you up to date on the Connect (MyServers) plugin?    That looks like a message that would be generated by that plugin.

If you are replacing a data drive then you can use the Parity Swap process to update a parity drive to 14TB and use the old 10TB parity drive to replace the data drive.

You normally get a response within hours from support so it definitely cannot help to try again.

You would need to add Limetech.   I assume there is a good reason as otherwise I do not see why they would have specified that. limitation.

Looked on my test system and that is set to 50MB so that is probably the default as I cannot think why I would have changed it there.

That looks like you do not have a genuine licence.

You have to make these two steps and let one complete before attempting the other.  I would recommend upgrading the parity drive first.
 

Do you really mean it reboots rathe than just freezing so that you have to manually reboot?
 
if you really mean it is rebooting then it is almost certainly hardware with the most likely culprits being the PSU struggling or thermal issues such as CPU overheating.

You must still have the standard parity check set to the schedule when you want the parity checks started, but you must set the Cumulative Parity Check setting to No if you are using the Parity Check Tuning plugin to handle pause/resuming of increments. 
 
I'll reword that message to make it slightly clearer.
 

I see this in the syslog
Mar 13 03:40:01 PolaFlix kernel: XFS (md1p1): Metadata corruption detected at xfs_dinode_verify+0xa0/0x732 [xfs], inode 0x200000b7 dinode Mar 13 03:40:01 PolaFlix kernel: XFS (md1p1): Unmount and run xfs_repair You should run a check filesystem and repair on disk1 to fix this (via the GUI).
 
Less important I see this:
Mar 12 14:27:00 PolaFlix root: Fix Common Problems: Warning: Share La Biblioteca de Pola set to not use the cache, but files / folders exist on the cache drive which you probably also want to fix.
 

You should consider posting the xml for your vm so we can see how it is configured.

The SMART checks happen BECAUSE a drive has just been spun up so this is a symptom, not a cause. You need to identify the cause by a process of elimination by disabling everything that could access the disks (docket, VMs, LAN clients) and then bringing them on one at a time.