Cloudron Forum

Even though I thought cloudron-support --troubleshoot had already done this, i tried docker system prune -a --volumes again and managed to free up 2.954GB - now updating

You’ll find way too many horror stories if you search for Contabo on this forum. I had the nvme plan and the speeds were constantly under 500mb/s. Support was useless. Frequent network issues were common. I’ve since moved to Hetzners dedicated vcpu entry plan that costs less than half but performance is top notch. It’s hosting my public facing sites while the rest are self hosted on premise. Before you go nuts trying to fix things on Contabo, go through a migration to a new provider and see how it goes. Use dry run feature when setting up the dns so the live sites are still using Contabo for now.

we're getting closer, this is a part of the scheduled one this morning: 2026-02-06 06:09:31,611 WARNING Could not figure out development release: Distribution data outdated. Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details. 2026-02-06 06:09:31,612 INFO Starting unattended upgrades script 2026-02-06 06:09:31,612 INFO Allowed origins are: o=Ubuntu,a=jammy, o=Ubuntu,a=jammy-security, o=UbuntuESMApps,a=jammy-apps-security, o=UbuntuESM,a=jammy-infra-security 2026-02-06 06:09:31,613 INFO Initial blacklist: 2026-02-06 06:09:31,613 INFO Initial whitelist (not strict): 2026-02-06 06:09:46,207 INFO Packages that will be upgraded: libc-bin libc-dev-bin libc6 libc6-dev libssl3 linux-generic linux-headers-generic linux-image-generic linux-libc-dev locales mysql-client-8.0 mysql-client-core-8.0 mysql-server-8.0 mysql-server-core-8.0 openssl screen 2026-02-06 06:09:46,208 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log 2026-02-06 06:09:48,505 ERROR Installing the upgrades failed! 2026-02-06 06:09:48,505 ERROR error message: installArchives() failed 2026-02-06 06:09:48,506 ERROR dpkg returned a error! See /var/log/unattended-upgrades/unattended-upgrades-dpkg.log for details 2026-02-06 06:09:48,952 INFO Package libc-bin is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:48,954 INFO Package libc-dev-bin is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:48,956 INFO Package libc6 is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:48,957 INFO Package libc6-dev is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:49,016 INFO Package libssl3 is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:49,037 INFO Package linux-generic is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:49,044 INFO Package linux-headers-generic is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:49,051 INFO Package linux-image-generic is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:49,058 INFO Package linux-libc-dev is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:49,165 INFO Package locales is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:49,172 INFO Package mysql-client-8.0 is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:49,174 INFO Package mysql-client-core-8.0 is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:49,175 INFO Package mysql-server-8.0 is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:49,177 INFO Package mysql-server-core-8.0 is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:49,189 INFO Package openssl is kept back because a related package is kept back or due to local apt_preferences(5). 2026-02-06 06:09:49,224 INFO Package screen is kept back because a related package is kept back or due to local apt_preferences(5). The mentioned /var/log/unattended-upgrades/unattended-upgrades-dpkg.log: Log started: 2026-02-06 06:09:46 Preconfiguring packages ... Preconfiguring packages ... dpkg: unrecoverable fatal error, aborting: unknown system group 'netdata' in statoverride file; the system group got removed before the override, which is most probably a packaging bug, to recover you can remove the override manually with dpkg-statoverride E:Sub-process /usr/bin/dpkg returned an error code (2) Log ended: 2026-02-06 06:09:47 This is a left over of a "total" removing (2 weeks ago) of netdata installation years ago (now we have graphs in Cloudron 9 we don't need it anymore), I did: sudo dpkg-statoverride --list | grep netdata root netdata 755 /usr/share/netdata/www root netdata 755 /var/lib/netdata/www ~# sudo dpkg-statoverride --remove /usr/share/netdata/www ~# sudo dpkg-statoverride --remove /var/lib/netdata/www ~# sudo dpkg-statoverride --list | grep netdata I'll check tomorrow if the nightly unattended upgrade did work. Thanks @James for pointing the right direction!

I investigated this on support@ . The issue was that the server had an incredibly slow disk and the iops was really bad (like 30MB/s) . The VPS provider is fixing their raid configuration .

Dedicated servers from OVH are well priced too, worth it in my opinion but it likely depends greatly by region. I’m in Canada and there’s only so many local options, with OVH servers being the cheapest by far but still very powerful. I’d only recommend OVH if you’re a pretty decent sysadmin though because their support is not the quickest.

@girish Thanks ^^ I've seen a similar post where the solution didn't helped on this and I though it was a good place to ask this. In the mean time I also issued this on github, about another database but with the same error and got a response that it's not a bug and indeed these type of databases, even if they use postgres are not supported. Guess I'll keep looking for alternatives that would fit my use case. Thanks for answering

@jdaviescoates said in Installed at map.bridport.coop then deleted, then reinstalled on same location: server not found: Is there a way to flush the NXDOMAIN cache on routers/ computers? Not that I am aware of. These days browsers also do their own DNS caching complicating things even more.

@LoudLemur Great, as you know many Apps here have other service ports opened, they just need to be packaged as such and include a webUI for config & health checks, etc.

@matthewdykstra Whoa! That’s crazy affordable. Ok, good to know. Thank you.

The best and easiest way is to use a single larger VPS to handle the different traffic apps. If uptime and stability are more matter in your case then you can run one app per VPS in critical services. Also, you can do a hybrid approach. The hybrid approach contains the separation of resource-heavy apps and low-traffic apps ones together. It can also work well. If you consider the cost then a single VPS is easier to manage and allows flexible resource allocation. But, it creates an issue like one application could impact others. Multiple smaller VPS instances provide better isolation and redundancy to one service that stays online if another fails. I prefer to use a single 4GB vps to a single app mostly. Still, if you want to use one vps for all apps then you have to prefer at least 8GB vps for sure.

Here is an ai generated list of potential solutions to some possible hurdles packaging molly brown: Here's the tidied section presented as a markdown code block: Potential Problems and Solutions Golang Version Compatibility Problem: Molly Brown requires specific Golang version compatibility. Solution: Specify the exact Golang version in the Dockerfile and ensure it's compatible with both Molly Brown and Cloudron. Configuration Management Problem: Managing configurations for different Cloudron environments. Solution: Use environment variables in CloudronManifest.json and modify the start script to generate a config file based on these variables. Persistent Storage Problem: Ensuring persistent storage for Gemini content. Solution: Define a volume in CloudronManifest.json for storing Gemini content, ensuring it persists across app updates and restarts. SSL/TLS Certificate Management Problem: Managing SSL/TLS certificates for the Gemini protocol. Solution: Utilize Cloudron's built-in SSL management if possible, or implement a custom solution in the start script to generate and renew certificates. Preserving Custom Configurations Problem: Updating Molly Brown without losing custom configurations. Solution: Store custom configurations in a separate volume and implement a migration script that runs during updates. Resource Allocation Problem: Efficient resource allocation in shared Cloudron environments. Solution: Carefully define resource limits in CloudronManifest.json and optimize Molly Brown's configuration for efficiency. Logging and Monitoring Problem: Integrating logging and monitoring with Cloudron. Solution: Configure Molly Brown to output logs in a format compatible with Cloudron's logging system, possibly using a log forwarding solution. Backup and Restore Problem: Ensuring comprehensive backup and restore functionality. Solution: Clearly define all data that needs to be backed up in CloudronManifest.json and thoroughly test the backup/restore process.

As of now, Im not having this issue anymore. I really dont know what would have caused this. Im thinking of setting up an opnsense firewall, not sure if it would help though

Thanks a lot guys, really appreciated for the input. Actually I am using vultr.com now, just made the upgrade of my server with it.

Debugged this with @ZeZaung a bit. Somehow, it was possible to re-run cloudron-setup on the existing install and this reset the database even though the app containers and data were still there. I have made a fix which should hopefully mitigate the problem.

@girish That's awesome, thanks Girish! Glad I wasn't crazy hahaha