Aha. Glad you got it solved!

Unfortunately, a few things things (possibly desktop) pull in all the virt stuff and it's hard to prevent from our side.

Interestingly, I have a Sagecom F@st 5655 device as a router. I did notice dnsmasq not dishing out DHCP leases and it was because the router was not connected to the internet due to upstream failures. However, I am running Amahi 12 and a newer DHCP, not your case (and also, it could be my HDA's netw...

Can you guys check again? It should be working.

Apologies for the down time. We are experiencing an issue with infrastructure that made this fix hard.

OK, this one has no exception either, but there is some evidence that hda-ctl is not running. Try (as root or sudo):

There is no error (exception) in this one (or POST of when you enter the good credentials).

Do you think you can try with good credentials, get the exception, and shortly after get the tail of the production log?

Looks like it's a session issue. Maybe the session cookies or their format changed.

Can you try to clear the cookies out for the domain corresponding to the url you use for accessing your HDA?

Yes, that will do it.

I packaged ca-bundle.crt and ca-bundletrust.crt in http://alpha.amahi.org/tmp/ca-bundle.zip in case you can use it. It's from a recent OS and I believe it may work.

Let us know.

Maybe try to just upgrade the CA certs.
Though of course that may fail. If it does, perhaps we can find links for you that can be used for direct install.

I think it will work though I am not sure.

Because 255 is considered a broadcast octet, I believe it's never used.

Maybe our DHCP server or DNS server complains, not sure, sorry.

I was briefly looking into this and they are not free, but some have paid options to protect from ransmware. It's an interesting problem that of ransomware. Look into Veeam Free, Macrium Reflect, FreeFileSync, Syncback, Synctoy, Cobian Backup, Robocopy scripting, urbackup server/client, Aomei Backup...