Cloudron Forum

Yep, as usual. It's user error. I was using the box config backup. I just had to adjust the backup path to point to the app. I figured out the correct path by logging into my Backblaze dashboard, browsed through the bucket (by date) and the file "name" is your path. Copy/paste into the import box along with the box settings and voila!

@philkunz said in No support for simply uploading a backup through the web ui?:

Ok got it. Is there a particular reason, why a simple upload through the webui is not supported?

In some ways, this can be considered a security issue. If we had some bug in Cloudron code, then one can import/delete your existing data in the app. This is also why we don't allow deleting backups via the web ui.

But (atleast I) have come around to this a bit. Maybe this can be considered a usability issue. We just need to figure out some safety hatch when user uploading a backup (maybe require 2fa, reenter password etc).

Hi All
Work it out IPV6 on the OS level

Need to make sure that is off ( will look at how to make sure the OS stop using it )

@gerard said in Restore v7.7.2 (Ubuntu 22.04) backup to v8.0.0 (Ububtu 24.04) system:

The release notes state an "initial support for 24.04" that doesn't sound like it's fully supported yet.

It should mostly work but we are just being a bit cautious here 🙂 There's a limit to how many VPSs we can test the installation on. We tested on the popular ones and seems to work, but one never knows.

The upgrade path for you would be to upgade to v8. Then later in 2-3 weeks time when v8 is considered more stable, you can migrate to a fresh ubuntu 24 with cloudron backups.

Sorry, but I am not following how name resolution is dependent on port 22. Name resolution uses UDP port 52 and is completely different from SSH which is TCP port 22 .

@ChristopherMag Wow, what a great story, with a happy ending, too!

Thank you for taking the time to tell us the tale.

I will mark this as solved, but if you hit this again please let us know.

@AmbroiseUnly yeah, good idea. I will add it to our internal list to check for backup existence to give quicker feedback.

@webthingz looks like this got missed. Did you figure this out?

Are you migrating using Cloudron backups ? If so, you can just migrate one by one using https://docs.cloudron.io/backups/#import-app-backup .

As for the license, you can just contact us to transfer the subscription to another server.

If you mean the webterminal, then this is into the filesystem of the app, not the host system. Cloudron does not have a webterminal into the host system, as it is not advised to tinker with this. However in this case you should use scp (essentially file transfer via ssh) to put the tarball into the /tmp of the server.

Ahh, I see.

Its always the simple things.

Thank you,

@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.

@girish yes correct my connection aborted. It's solved now

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

Ah great you managed to get this going!

@girish said in Make Cloudron Restore dialog more Human friendly:

Is there any easy fix which does not involved coding?

Yes, have the pattern available in the textbox so it's obvious what is expected.

It's more the "backup date/box ver file" than just a "path".

@andreasdueren yes, usually that means the passphrase is wrong.

Hi @mazarian,

in /home/yellowtent/platformdata/logs you will the file box.log, which should give an indication of what went wrong during your restore.

I did not check what the documentation says about this, but earlier this week I performed a restore in a similar manner to you and watching the dashboard during the restore there was definitely some parallel activity going on during the restore. I would have said that it was probably something like two or three apps at the same time max.

@Fairy this could be a bug in our Import UI, let me test and get back.

As a workaround till we fix:

Download the backup from GCP directly Upload it to somewhere in your server , say at /tmp Then, in import UI, choose Filesystem and give /tmp/app_xxx.tar.gz