I killed the apport proceses and that helped the server load and since restarted the server as well, but it seems likely that a failing SSD that I let go way too long is likely the culprit (sdb1 was were most of the apps were stored)... [image: 1771141770574-972bc655-c06b-471a-8622-639cc53de182-image.png] We'll see once everything is migrated and I try restarting... it's that initial boot up that seems to consistently take forever for the WP sites.

Ah ok, Cloudron doesn't wait for DNS to be in sync forever. It just waits for it at installation time and gives up after some retries. Maybe a feature request?

@jcalag said in uninstalled app not deleted: Errors were encountered while processing: nginx-core nginx-common It can't load the dashboard because nginx is not running. You can try some of the methods here - https://superuser.com/questions/1386209/how-to-solve-this-dependencies-apt-fix-broken-install

I have increased the solr indexing timeout and reduced the indexing batch size. Maybe it helps on slower machines .

Will do, James. I have not been able to recreate the held lock issue. I was starting/stopping jobs a fair bit at one point, and can't... be precise about where in the backup cycle those cancellations happened that a cleanup might not have happened. I will watch for it in the future. When I said there was no RAM pressure, I meant that was true for the server. However, my jobs all had 1GB of RAM. Your suggestion clued me in; because that value must be set after you setup the backup job, I had never noticed it before... or, not realized how critical it might be. I have bumped them all to 6GB of RAM, and so far, I've been seeing backup successes. Barring the question below, I'd say we could close this issue. The lesson learned is that I need to provide my backup tasks more RAM. Because I have some RAM to spare, I'm going aggressive, and giving things 6GB. I did not attempt to settle on a smaller amount, for anyone who comes along after--- I just gave the tasks a limit that I considered to be "a lot" in this context. I still see some things like the errors below. The backup completes successfully, but I'm unclear why there would be errors like these sprinkled throughout the backup. Is the relative path full/snapshot/app_... actually correct? Or, should that be a full path (e.g. the base path I provided at setup time along with the relative path)? In the command that succeeds, it is a full path. Feb 13 16:11:00 box:shell filesystem: ssh -o "StrictHostKeyChecking no" -i /tmp/identity_file_d82bc09e-a419-4d60-84bf-95d631fd0ebb -p 22 user@nas.lan cp -aRl full/snapshot/app_c74efccf-d273-46c9-8afe-3fd427bb78c1 full/2026-02-13-210356-064/app_git.jadud.com_v1.37.4 errored BoxError: ssh exited with code 1 signal null Feb 13 16:11:00 at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:82:23) Feb 13 16:11:00 at ChildProcess.emit (node:events:519:28) Feb 13 16:11:00 at maybeClose (node:internal/child_process:1101:16) Feb 13 16:11:00 at ChildProcess._handle.onexit (node:internal/child_process:304:5) { Feb 13 16:11:00 reason: 'Shell Error', Feb 13 16:11:00 details: {}, Feb 13 16:11:00 stdout: <Buffer >, Feb 13 16:11:00 stdoutString: '', Feb 13 16:11:00 stdoutLineCount: 0, Feb 13 16:11:00 stderr: <Buffer 63 70 3a 20 63 61 6e 6e 6f 74 20 73 74 61 74 20 27 66 75 6c 6c 2f 73 6e 61 70 73 68 6f 74 2f 61 70 70 5f 63 37 34 65 66 63 63 66 2d 64 32 37 33 2d 34 ... 50 more bytes>, Feb 13 16:11:00 stderrString: "cp: cannot stat 'full/snapshot/app_c74efccf-d273-46c9-8afe-3fd427bb78c1': No such file or directory\n", Feb 13 16:11:00 stderrLineCount: 1, Feb 13 16:11:00 code: 1, Feb 13 16:11:00 signal: null, Feb 13 16:11:00 timedOut: false, Feb 13 16:11:00 terminated: false Feb 13 16:11:00 } Feb 13 16:11:00 box:storage/filesystem SSH remote copy failed, trying sshfs copy Feb 13 16:11:00 box:shell filesystem: cp -aRl /mnt/managedbackups/1ec6c6b4-7566-4369-b2ce-466968b00d5d/full/snapshot/app_c74efccf-d273-46c9-8afe-3fd427bb78c1 /mnt/managedbackups/1ec6c6b4-7566-4369-b2ce-466968b00d5d/full/2026-02-13-210356-064/app_git.jadud.com_v1.37.4 Feb 13 16:11:07 box:backuptask copy: copied successfully to 2026-02-13-210356-064/app_git.jadud.com_v1.37.4. Took 7.889 seconds

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

@difficult222 I have replied to your ticket.

Thanks, fixed - https://git.cloudron.io/platform/box/-/commit/51e02da277d972d1d8b514dc15256f88e2fbe201

Hello @danskvandrelaug Can you please share the config of your /etc/netplan/00-installer-config.yaml file? Also what hoster are you using? Also the output of the --troubleshoot looks all good. What exactly is the problem?

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.

@girish probably for when we fixed the usernames having trouble with special chars and allowing just a dot which couldn't be deleted!

Fixed - https://git.cloudron.io/platform/box/-/commit/1ce5fcafd908c8362f57a7f6c1955591542bd895

Hello @jadudm Always happy to help.

Yes, you have to adjust the schedule manually to not overlap. Otherwise, if a single app is backing up to multiple sites in parallel, they will get serialized internally (with the lock).

There is also a Logs dropdown button in the backups view which opens the corresponding log file in the logsviewer, from there the full logs can also be downloaded, avoiding the need to ssh into the server.

@girish Can a migrations check be added to run until none remain, which hopefully evades the stuck condition too?

Hello @cbcun Great to read that you were able to resolve this issue yourself.

Hello @miednr Yes, for stopped apps a new backup will not be created since nothing has changed. See: https://docs.cloudron.io/backups#retention-policy For installed apps and box backups, the latest backup is always retained regardless of the policy. This ensures at least one backup remains preserved even if all backups fall outside the retention policy. This also preserves the latest backup of stopped apps when not referenced by any box backup. Did you know you can also archive apps? https://docs.cloudron.io/apps#archive

@girish Thank you, after upgrading to Cloudron version 9.0.17 (latest), everything started working again.

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!