Hello @teiluj Thanks for reporting. It could be that the CSA remembers the 2FA status and propagates it to the CSB, thus the 2FA not needed when CSA already validated that. But that is an assumption. We will have to look into reproducing this.

Hello @günter @Günter said: I restarted the "Filemanager" service, I restarted the whole machine. Via Web-CLI I can access the /app/data directories without any issues. When the Filemanager is opened on a Volume ("Volumes" -> "⋅⋅⋅" per volume -> "File manager") it also works fine and shows the content of all the apps in that volume. Just to confirm: view from web terminal of an app, working view from web file manager over the volume view https://my.$DOMAIN.$TLD/#/volumes, works view from web file manager from the app, still not working? I tried to reproduce this with these steps: attaching a new disk to my Cloudron server made the disk a ext4 with mkfs.ext4 "/dev/disk/by-id/scsi-0Linode_Volume_dev-volume" in the dashboard created the volume as ext4, named it dev-volume moved a fresh LAMP app default storage to Volume - dev-volume Subdirectory lamp could view the files with the Web File Manager from the app, volume and web terminal view confirmed by creating a dev.txt with the Web File Manager and checking with ssh if the file exists on the volume also tested without a Subdirectory Was not able to reproduce this. If the issue still persists, please contact support@cloudron.io so we can analyse this issue more detailed.

Hello @philkunz Can you please share the logs of the database that logs this?

Whoops, this should be fixed now. We made a bad fix couple of days ago in cloudron.io, and it was providing incorrect subscription information.

This was handled via support . The issue was related to docker storage corruption. Recreating docker images fixed it . And for the record, the issue was not related to 9.2 but 9.0.17 and still had ubuntu 20.04.

Not sure exactly the cause, however the app being backed up was peertube, and a update was scheduled and failed around the same time. The fix was deleting the corrupt file in the snapshot folder on my truenas from shell. Then re-running the backup

Hello @imc67 A surfer app that I just installed on 7.2 does have the admin note: To access the admin interface, visit /_admin.

Please re-open the topic if you hit the problem in the latest releases.

Hello, any update on this, I am looking forward to finding what else is hiding behind the problem. Sorry for all the work.

Given that nodejs is really meant for cloudron only, maybe this can simply be installed in the yellowtent home directory itself Maybe this will get solved by moving box code into it's own container as well.

@james Thank you for the offer James! @imc67 There is a loving community here for useful Cloudron solutions and you have one there by your own account. I am sure we can find help making a custom community app and possibly even a maintainer who will use it and love it daily. Like @timconsidine who has been scratching his own itches for some time, you did too and I for one am grateful for that!

Hi, The issue is fixed now. I backed up /etc/docker/daemon.json, deleted it, then ran: systemctl daemon-reload systemctl restart docker Docker is now running again and Cloudron/apps are accessible. Thanks for your help!

Great catch! This is fixed for the next release with https://git.cloudron.io/platform/box/-/commit/5e2b531d9bc4fc180395b58c704b1ee083b0aa5f

@joseph thank you so much! What a wild ride this was - I found the smoking gun by checking package manager logs: On 2026-03-29 21:23:20 I installed prometheus-node-exporter to ship metrics to my Grafana monitoring stack - apparently the workflow also installed iptables-persistent which installed netfilter-persistent as a dependency. why, I don't know - but lesson learned.

Hello @tyren_bm That is great to read! On another cautious note from me, Ubuntu 22 will be EOL May 2027. I know this is still one year into the future, but time is fleeting. You might want to upgrade your Ubuntu 22 to 24. Since Cloudron version 10 will also come with support for Ubuntu 26 this would mean that you'd only have to upgrade from 24 to 26 and not 2x versions when the time comes.

Hello @anthony-tran Can you restart the uptimeKuma app and provide us the logs from the web log viewer pasted to https://paste.cloudron.io/ ?

@sponch it's possible to slow down but we have to know what the rate limit is. I cannot find anything in our docs about this. Do you have happen to be in touch with their support?

I was under impression I'm quite clear... I don't think the decision made by authors correct. I'm forced to do the backup, even though there is no technical requirement for that. I'm forced to do the backup the way authors want, even though I have my remedies. As a result, I've just found out one Cloudron instance seriously out of date with a Docker security vulnerability in it. Just because authors decided that I have to have a backup to have automatic backup - to have my systems up to date. Not sure I follow that...

If the second contains the System backups it would include those of stopped apps, where a backup was made there (since otherwise the backup data simply wouldn't be there). But I agree this is not great to migrate. I guess for now you would have to start the app, make a full system backup on the scondary backup site and then stop the app again. The code for retrieving backup data for integrity check depeneds on format and storage type. Memory consumption is hard to predict, so presumably S3 with some kind of data on that storage just gets it over the 400MB