@salmonetc said in Changing DNS provider and email with minimal downtime.: I started trying to "add" the domain. However, I get the following error: Zone not found: 200 {"result":[],"result_info":{"page":1,"per_page":20,"total_pages":0,"count":0,"total_count":0},"success":true,"errors":[],"messages":[]} Have you added domain.com into cloudflare ? When you create a token also make sure that you add the domain in the Zone Resources list. See https://docs.cloudron.io/domains/#cloudflare-dns

Yeah, I think that was the problem. I have no idea what password was used because I tried quite a few of them! I ended up just biting the bullet and taking another backup with the proper password. It seems like it's working. Thanks for your help.

Thanks @girish , I've sent an email to the address you provided. I can see all the apps.

Thank you!

Maybe this was not clear from the start, on Cloudron all apps are pre-setup with databases already. The databases are also managed by the platform instead of the apps to allow proper backup points amongst other things.

Thanks sorry did not see that

This is not possible in Cloudron's Web Terminal . A slightly different approach is to just use a custom cron - https://docs.cloudron.io/apps/#cron . cron will run in the "background" and not attached to a terminal. Cron jobs logs are also sent to the App logs.

@cocam123 whoops, you are right! I forgot there is an option in the UI for this The exact checkbox text is Remote file system supports chown

Thanks @joseph ! I'll do that

As du is slow and resource hungry, maybe use an alternative? Diskus is a parallelized version: https://github.com/sharkdp/diskus, claims to be 5-10 times faster. Though not in the repos

Yes you can switch over the subscription to another server. Just send us a note about this to support@cloudron.io then

@falkfyre so did it work out?

@overholt said in Upgrade Cloudron on Linode: Which is the best way to do this? Personally I'd go with starting with a fresh server rather than upgrading Ubuntu I always do a dry run backup restore to check everything is working before updating DNS, see https://docs.cloudron.io/backups/#dry-run Note, when installing Cloudron on the new server be sure not to miss this Looking to restore link at the bottom here: [image: looking-to-restore.png] (I've missed it before and had to start all over again )

Just today I got a notification about an erroneous backup of the server where I have Nextcloud installed (150GB size) and I backup once a week.. I should add that the previous backups were successful. The provider is Backblaze B2. Oct 06 01:02:32 box:storage/s3 Upload progress: {"loaded":1073741824,"part":2,"key":"102/snapshot/app_50d07945-bf1b-4345-8e8c-c146e86c12a7.tar.gz.enc"} Jan 01 01:24:00 node:events:496 [no timestamp] throw er; // Unhandled 'error' event [no timestamp] ^ [no timestamp] [no timestamp] write EPIPE [no timestamp] at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:94:16) [no timestamp] 'error' event on TLSSocket instance at: [no timestamp] at emitErrorNT (node:internal/streams/destroy:169:8) [no timestamp] at emitErrorCloseNT (node:internal/streams/destroy:128:3) [no timestamp] at process.processTicksAndRejections (node:internal/process/task_queues:82:21) { [no timestamp] errno: -32, [no timestamp] code: 'EPIPE', [no timestamp] syscall: 'write' [no timestamp] } [no timestamp] [no timestamp] v20.12.2 Oct 06 01:02:32 box:shell backup-snapshot/app_50d07945-bf1b-4345-8e8c-c146e86c12a7: /usr/bin/sudo -S -E --close-from=4 /home/yellowtent/box/src/scripts/backupupload.js snapshot/app_50d07945-bf1b-4345-8e8c-c146e86c12a7 tgz {"localRoot":"/home/yellowtent/appsdata/50d07945-bf1b-4345-8e8c-c146e86c12a7","layout":[]} errored BoxError: backup-snapshot/app_50d07945-bf1b-4345-8e8c-c146e86c12a7 exited with code 1 signal null [no timestamp] at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:122:19) [no timestamp] at ChildProcess.emit (node:events:518:28) [no timestamp] at ChildProcess.emit (node:domain:488:12) [no timestamp] at ChildProcess._handle.onexit (node:internal/child_process:294:12) { [no timestamp] reason: 'Shell Error', [no timestamp] details: {}, [no timestamp] code: 1, [no timestamp] signal: null [no timestamp] } Oct 06 01:02:32 box:taskworker Task took 152.05 seconds Oct 06 01:02:32 box:tasks setCompleted - 2443: {"result":null,"error":{"stack":"BoxError: Backuptask crashed\n at runBackupUpload (/home/yellowtent/box/src/backuptask.js:164:15)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async uploadAppSnapshot (/home/yellowtent/box/src/backuptask.js:361:5)\n at async backupAppWithTag (/home/yellowtent/box/src/backuptask.js:383:5)\n at async fullBackup (/home/yellowtent/box/src/backuptask.js:504:29)","name":"BoxError","reason":"Internal Error","details":{},"message":"Backuptask crashed"}} Oct 06 01:02:32 box:tasks update 2443: {"percent":100,"result":null,"error":{"stack":"BoxError: Backuptask crashed\n at runBackupUpload (/home/yellowtent/box/src/backuptask.js:164:15)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async uploadAppSnapshot (/home/yellowtent/box/src/backuptask.js:361:5)\n at async backupAppWithTag (/home/yellowtent/box/src/backuptask.js:383:5)\n at async fullBackup (/home/yellowtent/box/src/backuptask.js:504:29)","name":"BoxError","reason":"Internal Error","details":{},"message":"Backuptask crashed"}} [no timestamp] Backuptask crashed [no timestamp] at runBackupUpload (/home/yellowtent/box/src/backuptask.js:164:15) [no timestamp] at process.processTicksAndRejections (node:internal/process/task_queues:95:5) [no timestamp] at async uploadAppSnapshot (/home/yellowtent/box/src/backuptask.js:361:5) [no timestamp] at async backupAppWithTag (/home/yellowtent/box/src/backuptask.js:383:5) [no timestamp] at async fullBackup (/home/yellowtent/box/src/backuptask.js:504:29) On other servers the backups are successful.

RESOLVED: It's likely that cloudflare was having some internal issue, but upon checking https://www.cloudflarestatus.com/ I was left more confused is there was any incident on their end in my region. It's buried under scheduled maintanaces and other stuff. I still not sure if this was the correct resolution, but it started working after executing these steps. sudo apt-get install -y systemd sudo nano /etc/systemd/resolved.conf Added the DNS of Cloudflare and google # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it under the # terms of the GNU Lesser General Public License as published by the Free # Software Foundation; either version 2.1 of the License, or (at your option) # any later version. # # Entries in this file show the compile time defaults. Local configuration # should be created by either modifying this file, or by creating "drop-ins" in # the resolved.conf.d/ subdirectory. The latter is generally recommended. # Defaults can be restored by simply deleting this file and all drop-ins. # # Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config. # # See resolved.conf(5) for details. [Resolve] # Some examples of DNS servers which may be used for DNS= and FallbackDNS=: # Cloudflare: 1.1.1.1 #cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111 #cloudflare-d># Google: 8.8.8.8 #dns.google 8.8.4.4 #dns.google 2001:4860:4860::8888 #dns.google 2001:4860:4860::8> # Quad9: 9.9.9.9#dns.quad9.net 149.112.112.112 #dns.quad9.net 2620:fe::fe #dns.quad9.net 2620:fe::> DNS=1.1.1.1 8.8.8.8 sudo systemd-resolve --flush-caches # didn't work systemd-resolve --status # wasn't even running. So maybe the config change was irrelevant Reboot and started working... and I am not sure how this is possible... Anyway that for the help. This issue was plaguing me for a few days.

@jtippetts atleast the dashboard seems up now. Not sure why the machine shutdown itself though.

Awesome, I couldn't get NFS to mount, so just set the tarball option instead, thanks.

Things work like a charm indeed. I'll likely move the vps over soon or later once answering the question of where I should go. Also looking for a good option for CI/CD runner and to mitigate most issues faced this last month with Contabo.

Switching to hetzner feels good enough for now . Full backup takes 30min for 21 apps. I've cancelled contabo storage service. Hope this stays so snappy for the long run

So wildcard is only for subdomains of a domain. The domain.com record is not covered by wildcard. But yes the instructions probably sound like both *.domain.com and domain.com are in fact managed by Coudron, but all I can tell you that unless an app is using a domain, the certs will not be renewed. Maybe we can be smarter about this in the future, but to solve your problem this is what is required. Note a redirect to an existing app will also work.