It won't let me change it. root@sftp:/etc/ssh# chmod 600 ssh_host_rsa_key chmod: changing permissions of 'ssh_host_rsa_key': Read-only file system root@sftp:/etc/ssh# sudo chmod 600 ssh_host_rsa_key chmod: changing permissions of 'ssh_host_rsa_key': Read-only file system

Following up on this, if it errors out, then maybe the domain menu could show a warning. This is at least where I would expect it.

@joseph said in Old system backups are not listed: wonder if the backupcleaner removed the entries from the database by mistake. Have you tried searching for the old backup in the eventlog? Maybe it hits one of the backupcleaner tasks . Just a thought. Thanks, Joseph. I checked the Event Log, but I don’t see any entries from backupcleaner or anything indicating that older backups were removed or pruned. All older backup folders are still present on the storage, but Cloudron simply doesn't list the system backups created before the upgrade to 9.x. To clarify: Older app backups are visible under each app, but older system backups are missing entirely, and restoring an older app backup fails with the fsmetadata.json ENOENT error. So it doesn't look like backupcleaner deleted the files – it just seems Cloudron no longer recognizes the old backups after the upgrade. Let me know if there is anything else I should check.

Are we actually talking about the disk usage graph calculation or some app issue which causes downtime somehow? For the memory issue, since Cloudron components may be artificially limited to cause less side-effects if an app is faulty, the limit could be reached and a process thus get killed by the kernel, despite having free memory on the overall system. Thus would be good to see the output of the system logs via journalctl --system at around the time of the process ending.

Hello @vk182 @vk182 said in Hiding apps behind the proxy app to enable cloudron authentication: Do I understand correctly, that proxyAuth add-on will respect the Access Control setting of the app and allow access only to the allowed users via their Cloudron authentication? The target app may want the extra auth then but that is fine. You understood correctly. @vk182 said in Hiding apps behind the proxy app to enable cloudron authentication: Is there a way to add proxyAuth for the existing app? Yes that can be done. You can think of that process like an app update, that only updates the app to use the Cloudron proxyauth add-on and does nothing with the application itself. @vk182 said in Hiding apps behind the proxy app to enable cloudron authentication: p.s. Just as a side note, what is the best way to isolate the particular app from the public interface? If you have apps, that should not be publicly accessible, you could always only allow connections from specific IP-Addresses like e.g. a VPN. Example setup could look something like this: Main Cloudron server - running the VPN app and all other public apps Separate Cloudron server - named intranet running all apps that should only be accessible from whitelisted IP-Addresses like the VPN (public IP of Main Cloudron) non-public apps on this Cloudron intranet server People who should be allowed to access the intranet server get a VPN client cert The Cloudron intranet server can be connected to the Main Cloudron User Directory, thus syncing users for apps that have OIDC/LDAP For the Intranet Cloudron server, you'd have to configure the firewall on a hosting provider level to only allow access from the Public IP of the Main Cloudron Thus isolating public from intranet and still maintaining the comfortable setup of Cloudron User Directory. Also comes in handy if you don't want your public apps (like Website or Shop) to go offline only when you need to update/reboot the intranet server.

@joseph excellent work. Seems like it was designed for an RPM distro.

@FrenchyBear @tecbox and you got the same error message but the issues were totally different. The fix I posted was for S3 (used by @tecbox). In your case, you are using gcs. It's a slightly bigger fix - https://git.cloudron.io/platform/box/-/commit/99c14533a5930a6175630b6c299a577d64f2decb . You can get the raw file from https://git.cloudron.io/platform/box/-/raw/99c14533a5930a6175630b6c299a577d64f2decb/src/storage/gcs.js and replace /home/yellowtent/box/src/storage/gcs.js .

Haven't encountered such timeouts from thunderbird, unless the network is actually flaky. Maybe check if both ipv4 and ipv6 are setup but only one works? Could be that thunderbird (probably relying on the system's network interface selector) sometimes picks one of the two which resolves but does not route.

ohh yes thanks Cloudflare proxying is on. Turned off and all appears again- although I cannot quite work out exactly what is blocking it in cloudflare

@avatar1024 in the previous versions, one could change the backup format between tgz and rsync . We used to track the format of each backup (for restore from old backups to work). in Cloudron 9, you cannot change the backup format of a site once set. instead, you can just create a new backup site if you want another format. The migration code probably detected that you have backups in both formats. So, it would create two sites - one tgz and one rsync. That's what you are seeing .

@james @joseph thanks for your fast replies. I managed it with the hint from joseph and also created a new api token. Works well now. thnx!

ok thanks, below the result after just a few minutes, I'm not a technician but as far as I can see it's mainly mysql which is writing (I sorted Write): [image: 1764682318506-de0b4ce4-096f-4c6b-977b-dcf6574125ea-scherm-afbeelding-2025-12-02-om-14.30.00-resized.png]

@saikarthik I deleted the registry config. mysql -uroot -ppassword -e "DELETE FROM box.settings WHERE name='registry_config'" Then, re-run the migrations: /home/yellowtent/box/setup/start.sh After the upgrade, you can re-setup the registry . But you have to shorten the password length to < 128 chars.

@necrevistonnezr @joseph Ah, got it, thank you for clarifying. For what it's worth, I was following the upgrade guide for Ubuntu 22.04 (https://docs.cloudron.io/guides/upgrade-ubuntu-22/) which indicates that it should be active. Probably a decent number of people will follow the same trail I did: Cloudron updates to 9.x --> Notification about 20.04 EOL --> Follow 22.04 upgrade guide. If none of these folks need to worry about the collectd step, it might be worth adding a note in the 22.04 guide. The 24.04 guide also mentions collectd. While it's fresh in my mind and I'm looking at it, is there any reason I should or shouldn't go ahead and upgrade to 24.04?

@joseph Thank you. That seems to have fixed the problem.

@nostrdev you can pass -p or --port-bindings to cloudron install . It will query it. You can also pass directly using -p NEO4J_BROWSER_PORT=someportnumber,BOLT_BROWSER_PORT=anotherport .

The mysql db was corrupt beyond repair. I reimported from a back up and things are good.