@joseph Yep, this was my installation Thank you very much @joseph can't thank you enough.

We will show the domain, for which the API call failed, in the error message for a start with next release. https://git.cloudron.io/platform/box/-/commit/f421fd771ff0e0550381d012414a6c35c8fd2afe

@RoloufGoudebin just to take a step back. Can you give us more background as to what happened to the server? Trying to understand why node symlinks have disappeared. If you can write to me at support@cloudron.io with more details, I can take a look.

@girish Thank you, girish for the update!

@dylightful Which provider are you using to backup files? What version of Cloudron are you using?

@girish Thanks ! I replaced the /home/yellowtent/box/src/storage/gcs.js with the patched version and don't get the "old backup not found" error. the backup is listed in System backups. everything seems to be fine ! Thanks a lot for your help !

Fixed in https://git.cloudron.io/platform/box/-/commit/9773c02e7d6fda7a9704ad8866d7e16ba11dcae3

The code actually would fetch more pages until it starts scrolling to fill up the screen, but only of course if there are enough results to show: https://git.cloudron.io/platform/box/-/commit/b53da61e7cec3c919ac11ebd65a8ccce03f7f611 Maybe there is some other bug you are hitting, here on this screen if I change page size to 5 it fetches about 20 pages

Changing the database schema manually is usually always a bad idea. It becomes very hard to apply the database migration scripts which have to be run one-after-the-other and with manual changes it is unknown at which schema state the database is and if subsequent migrations can work. Do you know exactly which SQL query you ran manually to update the schema? If so ideally revert that and run db migration script again. It probably will just show the same error as before, so we can work from that on. Duplicate entry '20647655-d757-412a-8a67-3b6ff3d224a3-oidc' for key 'oidcClients.PRIMARY' it seems like you have duplicate records in the oidcClients table. Can you run: mysql -uroot -ppassword box -e "SELECT * from oidcClients" Then find the duplicates and remove one of them. Then rerun the migration script again.

@joseph I guess you are right. I'm trying to figure it out. My son is working a lot but I'll try go get access to his computer through Tailscale so I can reach the local network with a desktop and UI and try to reset the router.

Minio is basically dead for community edition. I rolled back to image: quay.io/minio/minio:RELEASE.2025-04-22T22-12-26Z (last version with all management features - don't expose it publicly for security reasons) Then: Configuration > Region > Restore Defaults That wiped my region entry and now Cloudron connects properly again. Time to consider successor software now.

Success! Thank you!

yes- was my error/ all resolved. Issue was I had disabaled some of the app backups under app level but then had selected to back these up in global settings but seems the global settings do not overide the app level backup settings/ nor is there anything in global settings to inform backups for sepcific apps have been turned off at app level (maybe this could be added).

@luckow not sure if that is the right expectation, you have to use env vars. Password is just one or the many config vars of an addon. Addons can change because of user actions. For example, a user changes the SMTP addon address, user changes internal ports of an addon, user changes oidc scopes etc. In many PaaS setups, they will cycle passwords periodically, so hard-coding will never work even if you don't move instance in the long run. The behavior is the same in all app deployment platforms - heroku, DO app. See https://devcenter.heroku.com/articles/add-ons#config-var-values-can-change for some rationale.

@webmaster we do offer direct support for businesses. We have a business plan exactly for businesses such as yours. If you are on a business plan, you can contact us at support@cloudron.io and we respond in a day.

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

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.

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