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.

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!

@Kubernetes my bad, typo... fixed now.

Cloudron does not set the CSP header unless a custom one is specified in the app configure view in the security page. However apps may set this on their own, either through headers or also as meta tags in the delivered pages. Cloudron does not interfere here. This is however a topic for each app which is not setting those according to your needs.

I solved my problem by updating Cloudron to version 9.0.17. There’s no longer any need to run a backup before a manual app update.

@james thanks!

Looks like there was a temporary issue with Hetzner routing. It's fixed now.

@james said in Bug in user selection UX and dashboard visibility setting in external link configuration: Hello @sansguidon I have looked into the issue and fixed it. Will be part of the next Cloudron release. Thanks @james

Thanks @james

@tecbox thanks for the update!

Hi @girish sorry for the delay. I think -D does not necessarily impact performance, my test after removing -D was much quicker but after adding it again it was just as quick. Seems like there's some kind of filesystem caching. Maybe at some point I could analyse the differences but I suspect changing this doesn't impact performance so much. The part that does impact performance a lot is the -x flag, but as far as I've seen, that will only prevent iteration on the remote (s3fs) filesystem if du is initiated on the parent dir, e.g. /mnt and not on the mount itself /mnt/s3fs. Would be a lifesaver if you could add this, but understandable if it cannot be done. If it cannot be done, a workaround to exclude certain volumes from disk usage calculation would be fine too. Or maybe you could add an option to the Disk Usage UI: Offer an option to include/exclude certain volumes before actually executing calculation

@jdaviescoates yes, there was a sshfs backup bug and I think 9.0.14 and 9.0.15 had fixed for exactly this. Unfortunately, Cloudron has no way to "force update" a bugged release.

@goseph10 that was a bug. I have fixed this in https://git.cloudron.io/platform/box/-/commit/1594d190eb29071c0aa11ff0a0e48554bb5fc04f You can edit /home/yellowtent/box/src/updater.js and fix line 229: if (!options.skipBackup && sites.length === 0) throw new BoxError(BoxError.BAD_STATE, 'No backup site is enabled to store automatic-update backups. Enable this in a backup site to continue.'); After that systemctl restart box

actually after looking closer in the code, the RRSet record api should also work as ich even for more records. It only would hit an issue, if one record has more than 25 values.

Hi @joseph . Thanks! Yes, the issue was with the encryption password. I successfully created a new app from the backup. However, one question remains: how can I restore a backup to NocoDB without recreating the app? The original restore (to the existing app) kept failing with the role already exists PostgreSQL error. Could this be related to memory limits? I checked and there seemed to be enough memory available everywhere. For context: my NocoDB has many records plus connections to external databases.

Thank you @james Increasing the part size has fixed the issue.

Thanks for you help