@timconsidine No worries and it's not that big of deal, really. I just wanted to mention it to help with troubleshooting and for others not to be discouraged from trying CCAI(P). I believe the staff wouldn't have considered this feature in 9.1 if it weren't for the success of CCAI. Kudos!

That is strange indeed. so curl -6 https://ipv6.api.cloudron.io/api/v1/helper/public_ip does not work on this server? If so then clearly the server is not correctly set up for ipv6, we should check then what is missing.

I sshed into the server, and the file really does not exist: cloudron# ls /home/yellowtent/appsdata/f6e82f5e-ae79-403b-b824-f96d8989b4f4/fsmetadata.json ls: cannot access '/home/yellowtent/appsdata/f6e82f5e-ae79-403b-b824-f96d8989b4f4/fsmetadata.json': No such file or directory The content of the directory: cloudron# cd /home/yellowtent/appsdata/f6e82f5e-ae79-403b-b824-f96d8989b4f4/ cloudron# ls -la total 2552 drwxr-xr-x 5 yellowtent yellowtent 4096 Jan 30 23:06 . drwxr-xr-x 4 yellowtent yellowtent 4096 Jan 28 19:35 .. drwxr-xr-x 3 yellowtent yellowtent 4096 Jan 28 20:07 2026-01-24-060000-602 -rw-r--r-- 1 yellowtent yellowtent 6343 Jan 31 23:06 config.json drwxr-xr-x 6 www-data www-data 4096 Jan 30 15:02 data -rw-r--r-- 1 yellowtent yellowtent 2582680 Jan 31 23:06 mysqldump drwxr-xr-x 3 yellowtent yellowtent 4096 Jan 28 20:15 snapshot

Is the IP address correct? It has to be the Cloudron server IP. Do you have a screenshot? Maybe OVH has changed their UI since we wrote those docs.

Hello @jcalag Please ssh into your server and run cloudron-support --troubleshoot and post the output here.

@james Yeah, first I tried backup from the app-menu, this crashed. It was a bit difficult to remove the app / data, but after some time I get it it uninstalled. After reinstalling, I changed all settings to previous settings manually - RAM and also data directory. Confusing is, the restore goes to the data directory, but after then, it created the mentioned other folders in appdata.

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

@dsp76 yes, run.sh is called by start.sh . Cloudron downloads the backup. At this point, the users of all files are yellowtent. This is the user which Cloudron code runs as. Then , start.sh runs as root (from inside container) Which then calls run.sh Maybe the above helps debugging further.

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

They were only being embedded for the staff on our Nextcloud, not for the public. And we did restrict to our internal domains and had the same issues. Just thought people should know that some apps don't work at all with CSP, causing these apps GUI to stop loading complely making it look like the app no longer works.

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

Thanks for you help

Right, the haraka log can be ignored. I think the IP and cert name don't match and thus the warning. It's not a problem since such mails don't leave the server.

Hello @supaiku Are you using the @wordpress-managed or @wordpress-developer app?

I have this running too I thanks I have ork this out will update this post so if someone need to do it but thanks for the help sure I got it now I have found he keys ssl_certificate /home/yellowtent/platformdata/nginx/cert/_.XXXXX.cert; ssl_certificate_key /home/yellowtent/platformdata/nginx/cert/_.XX.key; just need to make a scp for on changes and to send a copy to the 2nd server..... Nozy

Once the DB gets busy, big or the storage gets slow, consider to copy the .db file first then dump from a DB file that isn't changing.