Right, the 1GB instance actually has 941MB. I have fixed the setup script accordingly. ubuntu@ip-172-26-13-174:~$ free -m total used free shared buff/cache available Mem: 941 194 335 0 410 606 Swap: 0 0 0

Can't help with virtual box since I have not used it. On a side note, from Cloudron 8, we will start supporting machines without AVX again. In such situations, you won't be able to use MongoDB or apps that use MongoDB.

@darsh_parsana /home/yellowtent/box/setup/start/cloudron-firewall.sh is on the root system, not inside any container. You can just edit the file directly via ssh.

@darren if you hit any issues, feel free to ask here.

A little update on this: I help a friend migrating their cloudron to another server and set-up a new backup storage (also using a Hetzner storage box). Server migration worked fine (that was not using the Hetzner box). When it came to connect the new storage box we faced issues. We generated 4 pairs of ssh keys: rsa with paraphrase ed25519 with paraphrase rsa without paraphrase ed25519 without paraphrase With all four we could connect to the storage box from outside cloudron (using terminal or from file manager). 1. and 2. required the paraphrase to do so. On Cloudron: and 2. didn't work >> expected as paraphrased is required worked just fine if trying to connect to the box by created a new volume or a new backup storage the connection failed as reported above in this thread. BUT if the volume or backup storage was already present and mounted (using key 3.), then I could go to the settings and replace key 3. by key 4. and then it connected fine. Maybe this description might help tract where the issue comes from, since it only happens when mounted a new valume/backup and not when it's already present

@girish great, thank you. I plan to move all my e-mail accounts to my cloudron server

@micmc yes, already implemented the crash fix -https://git.cloudron.io/cloudron/box/-/commit/d862f1f5b4f10b5852aed958ecc4ce42709103f7 . CF was returning an invalid response that our code was not prepared for.

@girish Thank you very much. We run the tests again by reinstalling it again. It seems that the problem originated when we installed multiple Apps and then UptimeKuma somehow broke. So we installed them one by one, and now it's ok.

@marylou Lots of unpack here. Are you able to contact us at support@cloudron.io and we can try to see what's going on in the server.

I didn't uncover the cause, but I believe it was related to the VM running out of disk space. I wound up reinstalling. I let a large upload job run unattended and wound up completely filling the drive on the VM running Cloudron. I then cleared about 100 GB, rebooted for good measure, resized the partition using parted, expanded the filesystem, rebooted again, and let it run normally for a few days. That's when I noticed I couldn't install any new apps. I suspect that either the partition / filesystem resize or the disk being full broke something internally. In hindsight I wish I had taken the time to dig into the logs a little more and see what was happening. But this is likely a direct result of my unusual environment fault.

@gog122 you can login at https://console.cloudron.io/#/login and cancel it there.

This was sorted out in support.

@nebulon I hit many road blocks indeed, but managed to move quite well forward now i'm at the part of the npm rebuild and I can't do the db-migrate because I don't see any npm install being done that provides db-migrate within nodes_modules/.bin folder I have documented the changes I had to do in the different install files to get it working, i can share this to the support email if you're interested

@nebulon I don't really know the S3 system they used

Thanks for the hint - trying that I got a more meaningful error notice. It was one of the ipdeny urls (IPv6 list for North Korea) that resulted in an empty HTML file, throwing off the ipfile format.

@im-fabian does using the psql command directly work? That will help us debug if this is mistake in postgres credentials or some pgadmin issue.

@Vortexapps this seems to be VM/deployment related. You have to tell us more about your setup / network for us to help further. nginx is running as you see in the troubleshooting output, so you have to check why it's not reachable by ip on port 443.

@Dave-Swift 7.7.2 is in the CI. So, in a day or two.

@ekevu123 good idea!

@girish Yup I posted it here, really for search results in case other people come up with the same issue ! it can be marked as solved !