The comma is a delimiter and can cause problems with some mailservers. Have you tried putting the name inside double quotes?

I'm struggling with this problem as well. I'm finding when I try and SSHFS with my TrueNAS box... Assuming the user is cloudback The path is /home/pool/dataset/cloudback I set my backup path to /home/pool/dataset/cloudback and my prefix to full Cloudron always changes the permissions on the directory /home/pool/dataset/cloudback to 777. This seems... grossly insecure. And, worse, it breaks SSH, because you can't have a filesystem above the .ssh directory with permissions that open. However, I also find that if I set the path deeper into the account (with no prefix), I avoid the permissions issue, and instead, I get backups that hang/lock, especially on Immich. (That could be unrelated.) My single biggest question is why is Cloudron setting perms to 777 anywhere? I'm trying again by creating a directory in the homedir, and using that as my base path. Then, within that, I'm using the "path" option to create subfolders. I don't have a reason I think this might help, but given comments above, I'm trying it.

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

Yes, I have three backup destinations. But, I see und understand that's not a good idea to do multiple backups at a time... My server is not on limits (CPU 5%, RAM 33%, Disk I/O and Network I/O are low). I think, it will run through, but it's slower than doing the backups one at a time. But the reason seems to be the "lock" of Apps by Cloudron Backup. Will not repeat that... But for now, I will let the system find it's way during the night.

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

I deleted everything on S3 and then made a fresh backup and tried to import again: Same error. This is the structure on hetzner: [2026-02-07 14:12:46 CET] 3.1MiB STANDARD 2026-02-07-131010-053/app_example.com_v1.4.0.backupinfo [2026-02-07 14:11:58 CET] 8.3KiB STANDARD 2026-02-07-131010-053/app_example.com_v1.4.0/config.json [2026-02-07 14:11:58 CET] 428B STANDARD 2026-02-07-131010-053/app_example.com_v1.4.0/fsmetadata.json [2026-02-07 14:12:46 CET] 4.0GiB STANDARD 2026-02-07-131010-053/app_example.com_v1.4.0/mysqldump [2026-02-07 14:11:58 CET] 3.1MiB STANDARD snapshot/app_0245750c-82b5-4b4c-b6ea-15c53d6046b6.backupinfo [2026-02-07 14:11:07 CET] 8.3KiB STANDARD snapshot/app_0245750c-82b5-4b4c-b6ea-15c53d6046b6/config.json [2026-02-07 14:11:07 CET] 428B STANDARD snapshot/app_0245750c-82b5-4b4c-b6ea-15c53d6046b6/fsmetadata.json [2026-02-07 14:11:57 CET] 4.0GiB STANDARD snapshot/app_0245750c-82b5-4b4c-b6ea-15c53d6046b6/mysqldump Still same error: box:backupformat/rsync Recreating empty directories in {"localRoot":"/home/yellowtent/appsdata/f6e82f5e-ae79-403b-b824-f96d8989b4f4","layout":[]} Feb 07 14:19:49 box:apptask run: app error for state pending_import: BoxError: Error loading fsmetadata.json:ENOENT: no such file or directory, open '/home/yellowtent/appsdata/f6e82f5e-ae79-403b-b824-f96d8989b4f4/fsmetadata.json' at restoreFsMetadata (/home/yellowtent/box/src/backupformat/rsync.js:188:38) at Object.download (/home/yellowtent/box/src/backupformat/rsync.js:290:11) at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async download (/home/yellowtent/box/src/backuptask.js:129:5) at async Object.downloadApp (/home/yellowtent/box/src/backuptask.js:169:5) at async installCommand (/home/yellowtent/box/src/apptask.js:341:9) { reason: 'External Error', details: {} } Feb 07 14:19:49 box:tasks setCompleted - 3594: {"result":null,"error":{"message":"Error loading fsmetadata.json:ENOENT: no such file or directory, open '/home/yellowtent/appsdata/f6e82f5e-ae79-403b-b824-f96d8989b4f4/fsmetadata.json'","reason":"External Error"},"percent":100} Feb 07 14:19:49 box:tasks updating task 3594 with: {"completed":true,"result":null,"error":{"message":"Error loading fsmetadata.json:ENOENT: no such file or directory, open '/home/yellowtent/appsdata/f6e82f5e-ae79-403b-b824-f96d8989b4f4/fsmetadata.json'","reason":"External Error"},"percent":100} Feb 07 14:19:49 Exiting with code 0 Feb 07 14:19:49 box:taskworker Task took 171.978 seconds Feb 07 14:19:49 BoxError: Error loading fsmetadata.json:ENOENT: no such file or directory, open '/home/yellowtent/appsdata/f6e82f5e-ae79-403b-b824-f96d8989b4f4/fsmetadata.json' Might be something wrong with the way I create the backup?

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

@james sorry of the late response I tried it, and it shows these data root@CloudronMain:~# cloudron-support --troubleshoot [OK] node version is correct [OK] docker is running [OK] MySQL is running [OK] nginx is running [OK] box is running [OK] unbound is running [OK] Dashboard is reachable via domain name [OK] Domain elevatecalls.io is valid and has not expired root@CloudronMain:~#

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 said in Migrating Cloudron to New Host Acci: You can follow the guide here: https://docs.cloudron.io/backups#steps, but for your old server. If it was unclear, I couldn't restore from a backup in the first place. I think whatever problem I was having in the first place caused that. But now I can't access the dashboard for the original instance anyway. Side note: Can a mod rename the thread for me? I realized I made a typo. Can "Acci" be changed to "Provider"?

@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

@Supaiku said in Graphite & SFTPwon't run?: I'm honestly not quite clear what graphite does, so I'm curious about that. Graphite helps with the graph rendering to collect stats. I don't use SFTP much, but still want thing runinng smoothly and didn't exactly figure out what the initial issue actually was... SFTP provides file browsing services for the containers i.e the Filemanager. Are the containers in "recovery mode" ? Both the containers are dying gracefully, so someone is stopping them explicitly ("waiting for xxx to die).

@pauliusl Debug this step by step: host my.domain.com on your laptop. Does it point to your server IP? ERR_NAME_NOT_RESOLVED When you are moving domains across provides this is quite common. The whole migration process is not atomic.