Cloudron Forum

kinda looks like networkd from the systemd suite is not able to get to an active state. That job basically checks for overall connectivity of the system and many services like unbound have a dependency on that. So first that systemd-networkd-wait-online.service needs to get up and running. Do you have any more error logs of that one? Given that the one thing you posted was about " No DNS servers specified..." might indicate the system itself has no DNS server. Usually this comes via dhcp (in your case a dhcp answer from the fritzbox) Did you configure anything recently around networking or your fritzbox as such? What DNS servers do you get on other devices behind that fritzbox?

Maybe the healthchecker cron job got stuck there for some reason.
Do you see regular log lines in /home/yellowtent/platform/logs/box.log (of in the system log viewer) which look something like:

2025-10-31T15:31:10.111Z box:apphealthmonitor app health: 6 running / 1 stopped / 0 unresponsive

If not, then run systemctl restart box and things should recover status wise. Then would be great if you could mail that box.log file to support@cloudron.io and hopefully we can see when it stopped and why.

That sounds unfortunate. The app being marked as stable on our side mostly refers to the package itself. For example if data is correctly migrated and if it starts up fine as well as basic functionality is working.

For app internal bugs it would be helpful to create upstream issues at https://github.com/dgtlmoon/changedetection.io/issues

Of course if it turns out the app is overall entering some instable state as to not be useful anymore for longer, then I guess instead we should maybe remove the package itself.

so there is the system -> eventlog view which has those backup.cleanup events which would also show if and what it cleaned up. There is also a log button in that view for the event, which should then have more info on why it cleaned up those backups. Once we have that we can check if there is a bug or not.

Good catch, that got lost during the transition. It is back now for next release.

Alright and have checked the eventlog, yet? If you filter by backup.cleanup events you should see which one triggered the cleanup, it will show in the eventlog entry details. If that is the case at least we know it came from there and not some migration issue.

Ideally then the logs for that run are still available to further get down to the issue.

Then at least there are no dangling ones in the database, so the migration script was working for a start.

What is the retention setting you have on that backup site?

Just to keep everyone updated, the github issue in question is https://github.com/danny-avila/LibreChat/issues/10311

oh! yes I forgot about that aspect of update control. Thanks for letting us know. I have set it now to show a stable update for all. Sorry for the confusion.

So the app is marked as stable from our side, I also don't think we even have the functionality to mark individual app versions as unstable. So not quite sure what you refer to. Do you have more info on that?

Also pushed a change to enable the dropdown search input for filters with more than 10 entries.

Right turns out the sorting in the grid view is actually by app id, which is just a uuid. That is indeed not great nor predictable.

I pushed a change to sort alphabetically by displayed label for a start now.

Ah glad you managed to get down the issue in the end.

Handled via support ticket

Ah yes we had a translation string bug in that menu. This is fixed in Cloudron 9 but the item should still work as "upload folder"

Yeah the idea was to just setup an oidc client credentials set with a redirect URI for the app, but not actually configuring the lamp stack to also use this. Same as with LDAP credentials.

You can test the branch from https://git.cloudron.io/packages/lamp-app/-/tree/oidc-support?ref_type=heads if you know your way around building a custom app.

Once installed you have to create an OpenID client in your Cloudron dashboard with /secure/redirect_uri and put the following in /app/data/apache/app.conf:

   # OIDCRedirectURI is a vanity URL that must point to a path protected by this module but must NOT point to any content
OIDCRedirectURI https://<your.lampapp.domain>/secure/redirect_uri
OIDCCryptoPassphrase somethingsecret

OIDCProviderMetadataURL https://<my.example.com>/.well-known/openid-configuration
OIDCClientID <clientId>
OIDCClientSecret <secret>

Then restart the app and then you may put those two lines in any .htaccess within your public/ folder which you want to protect from public access:

AuthType openid-connect
Require valid-user

I've added the ability for admins in the VPN app now to see clients from all users and also be able to revoke on behalf of them. New package including this feature was just released.

@arta since the database is corrupt already in your instance, you probably first have to restore the app. Then cleart some historical data and then perform the update.

Also just to keep in mind, increasing the memory limit of an app does not mean it will get all that memory allocated, but that is only the upper limit it may use if the system even has that amount of memory available.

Hm this should not really be the case. Can you check if the backups are still in the db table or not via SSH and:

mysql -uroot -ppassword box -e 'select id,creationTime from backups where type="box"'

Also just to be sure, were they gone immediately after update or maybe purged by the cleanup job? The task logs there should hopefully give some indication.

Using an example setup, this works fine. Now we just need to decide if we should auto-provision oidc credentials with a fixed redirect callback URI or not.

If we do not pre-provision it, the Cloudron access controls won't be applied