Cloudron Forum

Yes, we released the new version just a bit ago. It works well now again. Thanks a lot!

We created an internal task for this, let's see when we get around packaging it. So far we had a very good experience with the other apps from @MiroTalk

This very much depends on the app which api you want to access. Often apps use accessTokens for this instead of login sessions. OpenID Connect is a subset mostly doing the authentication, but not the authorization here, so for REST API usage, I would prefer tokens.

Solved in support@

Just released a new app package with the upstream fix

Oh looks like docker was upgraded then outside of Cloudron updates maybe apt upgrade was called manually in the past.

The installer should have placed the correct versions in /tmp so run the following to manually install the correct version:

apt install --allow-downgrades -y /tmp/containerd.deb  /tmp/docker-ce-cli.deb /tmp/docker.deb

Then the update should succeed again

Thanks for sharing your findings here! Hopefully this regression gets fixed then with next release.

Are any containers constantly restarting causing maybe such a load on docker side? Is journalctl -u docker -f revealing anything?

You may have to ask the external storage plugin/app developers on how to use that. I haven't used this in years or maybe others here are actively using it?

Also have you looked around nextcloud forums and issue trackers for hints?

What does "mounted through the Nextcloud panel in CIF" for Nextcloud mean here? I guess those are not Cloudron volumes? Are you using https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/external_storage_configuration_gui.html ?

If so can you see the files in the webterminal of the app and also try to mount those to the server itself, to see if that mounting as such doesn't work?

Of course maybe you can also try to rollback the app. Nextcloud often has minor regressions with plugins, we try to be cautious and wait longer than usual for Nextcloud but we can't test all those combinations ourselves

Yes it is in our pipeline, but they changed quite a bit how they use laravel and introduced other issues which we have to fix. Somehow all script sourcing is now setup as http:// instead of https:// and thus the browser would block mixed content fetching on Cloudron. Something around the use of BASE_URL which we haven't pinned down yet.

Unless you want to restore the Cloudron itself, I guess we have to get down to this postgres issue. Maybe you can try to reset the postgres addon then following the steps at https://docs.cloudron.io/troubleshooting/#corrupt-addon

If that doesn't work we have to maybe get access to the server to see why it refused to start without further error messages.

So after some debugging, the actual fix is to enable the refresh_token grant type also: https://git.cloudron.io/platform/box/-/commit/16fa3390252e29f1803a18990c7b104817fa4d9f

Basically if you add this (also put back the previously suggested code bit) and sytemctl restart box then this should work also for existing directus instances I think.

Ah good, I was just struggling to reproduce the issue. What are the "default configs" in this case?

In case you still have logs until that, was there an error or crash in the mail service container or in /home/yellowtent/platformdata/logs/box.log otherwise not sure if we can do anything right now without being able to reproduce it.

Indeed looks like the postgres service does not come up, which is then blocking the platform startup to succeed. Haven't seen those postgres logs like this so far. We had some hiccups long ago with that postgres extension. Do you have more logs if you manually restart postgres?

Maybe check the logs at /home/yellowtent/platformdata/logs/box.log for more info to work with.

Do you mean packaging https://github.com/miroslavpejic85/mirotalkbro by live stream feature?

The email should contain a body with a link to the backup logs, but I assume those logs would have been empty also, if the disk was full. @girish might know better but maybe the mail container needs to write the body to disk which may have also failed then. Overall all kinds of things can go wrong if there is no disk space left as so far we weren't able to find a good solution on how to at least reserve a bit of disk space for crucial platform tasks. Recommendations are very welcome though

Forked this here, likely unrelated to the other topic from 4 years ago.

So on Cloudron app will get automatically pre-configured with email settings. The email solution runs locally on the system, so there is no need for encryption on localhost.

Do you have any error logs from the email sending attempt?