@shan Not sure what is going on. Can you contact us at support@cloudron.io ?

@girish ah ok, thanks, will try that!

@privsec said in Can not restore/reinstall cloudron: I have set up cloudron to use the same 7.5.2 version of my current install. On the new install after I update the DNS records to the new IP address, I get this After the cloudron installation, did you do the domain/dns setup and create an admin account? If so, you should not do that. Setup new server with cloudron --version 7.5.2 Go to https://ip For good meaure, I would power off your old server. This prevents any dns caching issues wrt my.domain.com pointing to your old server. Start restore from the setup view Cloudron will automatically navigate to https://my.domain.com 'Already activated' means that you already setup admin account on that server. After that, you cannot restore anymore for security reasons. For example, if you find a cloudron installation in the wild and try to restore, it won't work. That route is completely locked.

@privsec you have to start over with a vanilla ubuntu 22.04

@derryace No such route sounds ominous ... Which version of Cloudron is this? You can check this in the file /home/yellowtent/box/VERSION .

Yes i adjusted firewall. Added 443 port and now it works

ok, thank you

@fisi I think @nebulon responded to your ticket from support. If this is the same support ticket, the reason is that your server has 2 NICs and connected to the internal and external network. This is not a problem but the routes are set up incorrectly in ubuntu. The default route is going via the internal gateway. I think you have to adjust the netplan to fix the routing situation . (I hope I am replying about the correct tickte ! )

@nebulon has fixed this now for the next release. The first login (from admin setup or via invite) of admin account and normal users now has an OIDC session automatically. This means that when you click the first OIDC app, you are logged in automatically.

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.