I would say lets close this here. I do not see any failed cleanup jobs even multiple jobs try todo the same.

@nebulon Not so clear. The volume disconnected again. The "Remount Volume" button did not help but "Edit Volume" and saving (unchanged settings) worked.

Omg, for whatever reason the TLD did change from .de to .com (I have .de but not .com) so the failure was totally correct. No problems, nothing to see here, please close the case Happy holidays!

Thank you for this. I ended up creating a DO Spaces bucket, putting the backup there, and then restoring from that. To make it work, I had to use the Dry Run option and then manually sync the DNS. But now it is working. I wish that Hostinger had something akin to DO Spaces, but it doesn't, so I am still trying to figure out my strategy for offsite backups. Thanks @nebulon for your help!

Fixed now . https://git.cloudron.io/platform/box/-/commit/17fee930027896c405e8bbe3fbe56204c18c2670 . Thanks for reporting

@berryd great you sorted it out!

@timconsidine said in Domain cert renewal - when ?: I don’t even remember my own name. Your name is Timcon S'idine, just in case.

@scooke I’m interested in knowing too as I’d like to add a few more things to my set up like a hardware firewall, rpi nas, and blueiris (nvr cam system) that can be accessed remotely but also uses my ip and that definitely will conflict with the Cloudron server. But like you said, why over complicate things? It’s the only reason why i didn’t look deeper into this.

@crazybrad said in Unmounting volume leaves the "backup volume": Listmonk: Docker Error: Unable to pull image cloudron/app.listmonk.cloudronapp:202411131609490000. Please check the network or if the image needs authentication. statusCode: 500 This is the ipv6 rate limit issue which many are hitting. dockerhub seems to pushed some bad implementation of rate limits and it's wholesale cutting off network providers from accessing dockerhub. We have a workaround in place now for the new release.

On a brand new DO Ubuntu server, the first pull fails. root@my:~# TOKEN=$(curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:ratelimitpreview/test:pull" | jq -r .token) curl --head -H "Authorization: Bearer $TOKEN" https://registry-1.docker.io/v2/ratelimitpreview/test/manifests/latest % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 5429 0 5429 0 0 17471 0 --:--:-- --:--:-- --:--:-- 17512 HTTP/1.1 200 OK content-length: 527 content-type: application/vnd.docker.distribution.manifest.v2+json docker-content-digest: sha256:c2d41d2ba6d8b7b4a3ffec621578eb4d9a0909df29dfa2f6fd8a2e5fd0836aed docker-distribution-api-version: registry/2.0 etag: "sha256:c2d41d2ba6d8b7b4a3ffec621578eb4d9a0909df29dfa2f6fd8a2e5fd0836aed" date: Sat, 14 Dec 2024 15:41:35 GMT strict-transport-security: max-age=31536000 ratelimit-limit: 100;w=21600 ratelimit-remaining: 0;w=21600 docker-ratelimit-source: 2604:a880:2:d1::

Right, yes, that would make sense!

Thank you! I'm working through the platform updates now. I didn't realize it was so out of date, as I had automatic updates turned on. Discovered that the same issue causing my backups to fail was also preventing the platform updates from completing. Manually stopping the Snipe-IT app allowed the updates to complete successfully, so I'm assuming this will be resolved, but will follow up here if not. Really appreciate the assistance.

It was happening across multiple servers at the same time yesterday. Looks to be resolved now.

The issue is now resolved. The problem was with the GitLab database, where we found 160 GB of logs. The database dump was failing because there wasn’t enough free disk space. We have purged the database, and backups are now successful. Thank you for your support.

Thanks for the heads up. Added for the next release.

@imc67 said in Too many redirects when using Cloudflare DNS proxy: @Grienauer said in Too many redirects when using Cloudflare DNS proxy: I also had this problem. After researching etc, the solution is to set the SSL/TSL to Kustom -> FULL. Wow! Thanks for this very valuable information because now I’m finally able to use Cloudflare’s WAF!! (Cloudron as well as NetCup doesn’t have a WAF to ie. geoblock wp-login.php or other login pages). Certainly no equivalent to WAF but we do have blocklists to geoblock: https://docs.cloudron.io/guides/community/blocklist-updates/

@nebulon Fully agree, it's really odd that Wix doesn't allow AAAA records in this day and age. I'll change that domain to noop for now then as recommended, but my preference is to have the logic of the location DNS propagation check change so that domains in manual status can still be successful even if only one IPv4 or one IPv6 address is set rather than both. The noop is for development after all, isn't it? As long as one of the DNS records exists, that should be seen as successful IMO, since it will work in terms of getting traffic to the site still. There shouldn't be a reason to fail that.

Glad it worked out in the end

@diamantl should not be a problem. we will get to your mail asap.