TijuanaKez

Interesting that yours doesn't freeze up on Segmentation fault etc.
I also have a suspicion that the amount and kind of drives installed as this has an effect on power drawer and possibly integrity of the 12V and 5V rails.
Grounds for the suspicion:
Suggestion to raise VDD to 0.95V to improve stability as done with other Rockhip RK3399 boards Preventing the higher CPU frequencies makes it more stable. High CPU freqs are more demanding on power. The fact they shipped the unit with big electrolytic capacitors soldered to the end of wires on the Sata loom. Seems like a way to help smooth power rails without having to redesign the board. Various other hints here on the subject of VRMs, cpu governor settings, ramp time, latency etc in relation to the  RK3399. https://forum.odroid.com/viewtopic.php?t=30303
https://github.com/u-boot/u-boot/commit/f210cbc1f3d4f84baa595d83933369b4d6a529ea
https://github.com/u-boot/u-boot/commit/5a6d960b222203e60ab57e19b3eb7b41c24b564b
https://wiki.t-firefly.com/en/Firefly-RK3399/driver_pwm.html
http://patchwork.ozlabs.org/project/uboot/patch/20191128061433.1952869-2-anarsoul@gmail.com/
 
So, @mrjpaxton interested to know how many drives you have installed, and what type (5400, 7200, or SSD)?
Also a possibility is running fewer tasks on the unit means the CPU has less demand and the governor may by rarely, if at all, trying to switch into the higher problematic frequencies.
 
update: my unit still hasn't frozen again since last post with the 4000-14000 omdemand so things are looking pretty stable. so far so good anyway.
 
 
 
 
 
 

@mrjpaxtonI defintely bulit the unit corretly. As I said in the post, I had a %100 stable unit on OMV5 with the image listed in the wiki for years.
Paying attention to this forum though, it's clear stability issues have been long running for many users and from what I can gather, the root problem is to do with cpu and power management. Quite a complex subject, something that PC overclockers would know more about than me.
@snakekick thanks for chiming in too. Good info.
Collecting info as I find it, it does seem like preventing the CPU from hitting the high end is the best way to go (contrary to other posts here).
Still running on-demand 400-14000 now on @bunducafe's info, and it's more or less stable. As it's only happened once so far since changing to that setting, I can't even confirm it wasn't some other insult to the system
 

These sleep/susepnd modes are seperate from the hard drive power settings. You can still set power/spin down in OMV.
I't the Suspend to RAM state that is mentioned. Which probably means most of the states wont work by extension.
 
CURRENT branch (Linux Kernel 5.10)
Shutdown: OK 
Reboot: OK 
Suspend to RAM:  Not Supported. USB host controller refuses to enter suspend mode
Wake On LAN:  Not Supported. Suspend still have issue
 
 

whoops! Sorry for that mistake. This is Armbian forums after all,  I just dont really understand the inner workings of how the Armband is related to Debian. Just going off this from Kobol website.
 

 
Yes, well, well aware of how things went with Kobol and that this hardware is no longer supported officially.
This being the unmaintained section though (and because I know of no where else to ask) I was hoping to reach out any remaining Helios64 *users*.
Its never my intention to bother Armbian developers to help fix unmaintained hardware.
Hope you understand where I'm coming from.
I'm not ready to give up on this board yet as I still see nothing that compares features wise (number of sata ports), power consumption wise, size, form factor, and well...I own one.
Surely there are other users still using theirs?

I would suggest following this guide, and choosing the Portainer Stack option.
 
https://forum.openmediavault.org/index.php?thread/28216-how-to-nextcloud-with-letsencrypt-using-omv-and-docker-compose/
 
As well as being a streamlined and fairly painless way to install NextCloud and MariaDB at once, you'll get SWAG for free, which you will likely want.