@girish ok that clarifies it then.

@necrevistonnezr Thank you for your answere. I am just tryin to learn things step for step and take my time added you in discord Okay i never was been here before in this forum. this is sad what trolls are tryin i just here to improve my skills at the points where there are. clearly i am a little bit late with 29 to focus an such beginner things other learn with 15-19 but its never to late i guess

@jdaviescoates 🤭

@doodlemania2 that's exactly what the change fixes! it won't let you save that invalid config anymore (i.e putting a bucket name in the endpoint)

I figured out my issue. Turns out that even though I read the documentation I made one critical mistake right at the beginning. I had to create my email accounts and the addresses I wanted to work in Cloudron first. Then Install the Snappy mail client and set up the email accounts there second. Once I deleted the Snappy mail client and reinstalled it everything worked. I'm not sure how but this topic can be marked as resolved.

@girish Your question got me wondering what was going on. Turns out, two apps on the volume both had caches that were insane (one due to an old uninstalled WP cache plugin that was removed, but maintained its 12 MILLION cached files, and the other was Mastodon, which needed some manual cleaning for the 800k files it had cached). Turns out there were just SO MANY folders/files that any attempt to backup or read the size would just time out. D'oh!

Dont use Wasabi Use Idrive

@girish it seems the most recent update worked....while i did change some email settings, the only other action I took was manually bumping along the updates several versions. So there must have been some sort of inconsistent state that came up. It seems all is well with the world and no way to track down what happened. Thanks for the help, all.

This should be fixed with next release. It was a missing event handler.

I just jumped the gun. It was just DNS taking a while to propagate. All good now.

@mononym said in Cleanup Backups failure: I guess the issue is in the settings then? Check Backups -> Schedule and Retention -> Configure

@girish haha true, just wanted to throw that in there

@andreasdueren I'd be cautious about implementing it then. Cloudron hardens your server enough - doing more by installing more software, which is NOT recommended, will only lead to problems, especially if you don't already have a deep enough understanding of what is happening. It seems to be that @BrutalBirdie's gang knows their stuff (they're using Ansible to install Cloudron??? Yeah, that is next level coding there). Of course, they may also be paying for the Enterprise level of service (I'm not asking btw, no need to respond to that @BrutalBirdie ) so if they have hassles then I suppose it's fine for them to get help beyond typical Cloudron support, especially if they are doing more to their servers than what Cloudron themselves advise.

@privsec you can play with rclone mounts for this, however you want to minimize the network distance to avoid hiccups.

@girish said in Updating from v7.1.4: @cpa We moved out of AWS a while ago. Looks like older version of Cloudron is caching the old release. To fix: Delete the file /home/yellowtent/platformdata/update/updatechecker.json systemctl restart box Now , Settings -> Check for updates and then try to update Facing the same issue here, and this resolved it for me. And now I realized that my installation was multiple versions behind (like at least half-a-year behind), despite having weekly auto-update enabled. I'm afraid there could be more people like me who didn't check and didn't know it is stuck on 7.1.4.

@girish thanks for the explanation! Yeah the change happened ~14 hours ago and the TTL was set to 24 hours I reckon. I'll just wait until tomorrow to continue My plan would have been to lower the TTL a few days prior to the A record, so the caches would invalidate sooner.

Thank you. We use postmark as well. I am able to get in and everything is working. Thanks for your help.

Can just pass --redo to the setup script.

@Shaun-Snapp said in Add an A record manually for the domain: "Add an A record manually for www.abc.com to this Cloudron's public IP" I purchased the domain around 1/2 hour before trying to change an app to that domain. This is the error I received when the app failed to propagate. That message is saying that you have to add the A record manually in your domain provider (not in Cloudron). Cloudron cannot add/remove DNS entries for the domain because it's "manual" mode and thus has no programmatic access to your DNS. The place where you purchased your domain most likely has a Domain/DNS control panel where you can add/remove DNS entries.

@BrutalBirdie Thanks, it worked for me.