awesome as always, much obliged

You should do this - https://docs.cloudron.io/troubleshooting/#domain-issues-expiry

With help from Grok: https://grok.com/share/bGVnYWN5_baedbb67-0507-41f0-b26d-29da9f1b7f94 Exported users to delete with mysql --user=${CLOUDRON_MYSQL_USERNAME} --password=${CLOUDRON_MYSQL_PASSWORD} --host=${CLOUDRON_MYSQL_HOST} ${CLOUDRON_MYSQL_DATABASE} -e "SELECT id FROM user WHERE FROM_UNIXTIME(created_unix) > '2025-03-01'" > /app/data/users-to-delete.txt Deleted the header name with vim Switch to git user sudo -u git bash Run a command to use the cli to purge each user in the list: while read -r id; do /home/git/gitea/gitea -c /run/gitea/app.ini admin user delete --id "$id" --purge; done < /app/data/users-to-delete.txt All bad users cleared but one (not sure why), deleted manually. Done!

@d19dotca said in iDrive E2 Backups Failing More Frequently: What I had to do was delete the region hostname and re-enable it, which created my backup buckets somewhere else and allowed me to proceed without issue. The unfortunate part of this though was that it deletes all the files of course in the prior region, so what I did was first download a few important backups from it to my local disk and reloaded afterwards. I had the same rate-limiting issue with IDrive E2, but with a twist: my bucket was originally blazing fast in one region. After I deleted and recreated it (like you did), it became painfully slow—the exact opposite of your experience! I suspect their ‘region reassignment’ doesn’t guarantee consistent performance, maybe due to uneven server loads or hidden throttling. Moral of the story? With IDrive E2, if your bucket works fine, don’t touch it—even if they tempt you with ‘better regions.’

Ok if I switch it to "Direct disk" it fails to boot but "GRUB (Legacy)" kernel option seems to boot fine.

@nebulon wonderful, thank you for the clarification!

Thanks, I don't use cloudflare, but a good thing to be aware of.

Just tried this on the demo server. https://my.demo.cloudron.io (username/password is cloudron) [image: 1751631070055-fffc8926-44d5-49c4-af87-f77371ab2e98-image-resized.png]

Hello @shrey This is expected. Each Cloudron release and update has to treat every system the same and can not respect changes made by the user. Changes made to the core services need to be managed by the user manually.

Are you saying you are getting SPF_SOFTFAIL for all your emails? Note that the SPF fail here is for the domain of the incoming mail and not your domain itself.

I suppose it can be marked as solved, but I still run into questions and small issues.

@girish IPv6 is enabled on the server but not "in use", since some domains that are added manually don't have v6 and I don't want to run into troubles. Those are mostly Hetzner Cloud servers.

Thanks! I'm going to play around by modifying an existing app and see how far I get.

I will put in a feature request now and we can discuss further in that thread.

this issue has been resolved and the certificates have been renewed and access to the site has been restored. there was an issue with the server dns settings which was causing the certificates to not renew.

TTL issue ? I mean, this symptom lasted a very long time (a full year I'd say). Not seen since early June though. Maybe the "odd DNS issue" then. I guess this can be closed.

@arnej said in Problem with setting up a VPN tunnel from on premises machine to Cloudron in Cloud: there was a problem with the Cloudron internal firewall. Once he changed the settings there, the connection was established with no problem. Could you please elaborate what the issue was? Do we need to fix something? Also, useful for future readers who have a similar issue. I could bet you know the feeling of searching a solution and just finding a "I solved it, thanks" post somewhere and think yourself AND HOW?.

Hello @piedacoulisse For all subscription and payment related issues please contact support@cloudron.io directly! This should be resolved rather fast after you wrote the mail.

@ccfu I think that would be the best idea.