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

You may want to replace ssh with autossh, so that the connection is restored in case it stops working. This howto looks quite complete: https://m0agx.eu/yet-another-autossh-tutorial.html

@jdaviescoates said in Bug (?): since latest box version times are in AM/PM: with rsync backups and so backups are virtually instant as not a lot changes. But even with almost 200GB it takes about 2 minutes since the huge backup improvements lately!

Thx, I´ve look into that, it looks like the same!

https://git.cloudron.io/platform/box/-/commit/4992e284fbbe75652f195bfbc657c9a6b911b84d disables the potential squashing and wrapping for next release

Update: cloudron-support --troubleshoot returns: [WARN] netplan configuration is empty. this might be OK depending on your networking setup [FAIL] DNS is not resolving Further, /etc/netplan/ is empty. How do I generate the correct .yaml file to include there? Final Update: I was able to crate a netplan .yaml file by following these instructions.

Things often resolve AFTER posting. Weird.

Since porkbun returns an 400 error, I might guess something is wrong with the API call we do. Sadly https://porkbun.com/api/json/v3/documentation is not very detailed here, nor is the error message itself. Possibly the API requires something else for the naked domain, since the subdomains work apparently fine then. But also I can't find anything mentioned in the docs Can you check if this might be a record conflict error which just reports as 400? Like do A records for that already exist?

That answers my question. Thank you very much

@Algaweb are you proxying via Cloudflare or is there some application firewall or something like that? I have seen cases where Cloudflare throws a captcha screen which trips apps doing OIDC requests.