Specifically, the DO refcode is 933831d60a1e .

I'll create a new thread on this topic.

@DAMO11-coder see https://docs.cloudron.io/troubleshooting/#expired-domain

Apparently, there is a proper S3 bucket storage now. [image: 1679073227960-2a1b7338-dbca-49d7-864b-24dca54d3466-image-resized.png]

@opensourced yes, should be out next week along with 7.4

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