@james said in Migrating Cloudron to New Host Acci: You can follow the guide here: https://docs.cloudron.io/backups#steps, but for your old server. If it was unclear, I couldn't restore from a backup in the first place. I think whatever problem I was having in the first place caused that. But now I can't access the dashboard for the original instance anyway. Side note: Can a mod rename the thread for me? I realized I made a typo. Can "Acci" be changed to "Provider"?

@james thanks!

Looks like there was a temporary issue with Hetzner routing. It's fixed now.

@james said in Bug in user selection UX and dashboard visibility setting in external link configuration: Hello @sansguidon I have looked into the issue and fixed it. Will be part of the next Cloudron release. Thanks @james

@Supaiku said in Graphite & SFTPwon't run?: I'm honestly not quite clear what graphite does, so I'm curious about that. Graphite helps with the graph rendering to collect stats. I don't use SFTP much, but still want thing runinng smoothly and didn't exactly figure out what the initial issue actually was... SFTP provides file browsing services for the containers i.e the Filemanager. Are the containers in "recovery mode" ? Both the containers are dying gracefully, so someone is stopping them explicitly ("waiting for xxx to die).

@pauliusl Debug this step by step: host my.domain.com on your laptop. Does it point to your server IP? ERR_NAME_NOT_RESOLVED When you are moving domains across provides this is quite common. The whole migration process is not atomic.

Thanks @james

@Supaiku in addition to your high load average you also have two apport processes at the top of your list. So something has crashed or was killed and ubuntu is currently collecting logs for this.

@tecbox thanks for the update!

you should have mentioned earlier @james I wish I was aware that it is the problem! The whole cloudron is behind a haproxy that does TCP level proxy. From my understanding it should not affect, as it's one level below the HTTP(S) and WebSocket is above HTTPS. And the console doesn't seem to work for all apps terminals. Any ideas how to narrow down the root cause?

Is the IP address correct? It has to be the Cloudron server IP. Do you have a screenshot? Maybe OVH has changed their UI since we wrote those docs.

Hi @girish sorry for the delay. I think -D does not necessarily impact performance, my test after removing -D was much quicker but after adding it again it was just as quick. Seems like there's some kind of filesystem caching. Maybe at some point I could analyse the differences but I suspect changing this doesn't impact performance so much. The part that does impact performance a lot is the -x flag, but as far as I've seen, that will only prevent iteration on the remote (s3fs) filesystem if du is initiated on the parent dir, e.g. /mnt and not on the mount itself /mnt/s3fs. Would be a lifesaver if you could add this, but understandable if it cannot be done. If it cannot be done, a workaround to exclude certain volumes from disk usage calculation would be fine too. Or maybe you could add an option to the Disk Usage UI: Offer an option to include/exclude certain volumes before actually executing calculation

@dsp76 yes, run.sh is called by start.sh . Cloudron downloads the backup. At this point, the users of all files are yellowtent. This is the user which Cloudron code runs as. Then , start.sh runs as root (from inside container) Which then calls run.sh Maybe the above helps debugging further.

@jdaviescoates yes, there was a sshfs backup bug and I think 9.0.14 and 9.0.15 had fixed for exactly this. Unfortunately, Cloudron has no way to "force update" a bugged release.

@goseph10 that was a bug. I have fixed this in https://git.cloudron.io/platform/box/-/commit/1594d190eb29071c0aa11ff0a0e48554bb5fc04f You can edit /home/yellowtent/box/src/updater.js and fix line 229: if (!options.skipBackup && sites.length === 0) throw new BoxError(BoxError.BAD_STATE, 'No backup site is enabled to store automatic-update backups. Enable this in a backup site to continue.'); After that systemctl restart box

actually after looking closer in the code, the RRSet record api should also work as ich even for more records. It only would hit an issue, if one record has more than 25 values.

Hi @joseph . Thanks! Yes, the issue was with the encryption password. I successfully created a new app from the backup. However, one question remains: how can I restore a backup to NocoDB without recreating the app? The original restore (to the existing app) kept failing with the role already exists PostgreSQL error. Could this be related to memory limits? I checked and there seemed to be enough memory available everywhere. For context: my NocoDB has many records plus connections to external databases.

Thank you @james Increasing the part size has fixed the issue.

Thanks for you help

Right, the haraka log can be ignored. I think the IP and cert name don't match and thus the warning. It's not a problem since such mails don't leave the server.