Cloudron Forum

Amazing that is some very old typo apparently, never noticed either!

It is now fixed with https://git.cloudron.io/platform/box/-/commit/f82f3fa8587a99f71d840981d77acb0aca87ac2e

I see, well maybe you can explain how you intend to set this up. Like would Nextcloud be configured to use an external storage, or would you somehow mount the nextclouds main data folder as a volume into immich? Wonder how that would work and behave when apps get restored.

Generally if the apps support setting different data roots, this should be solved as explained with https://docs.cloudron.io/volumes/#sharing

But nextcloud, as far as I know, only supports that via its own external storage, otherwise you end up creating a volume based on internal platform folder paths, where the main nextcloud data resides.

I would strongly advise to not let both apps use the same data storage based on a filesystem. Both are designed to work through their own APIs to modify files/photos and they will eventually run out of sync.

The initial error was the outbound ipv6 connection which failed, so you have to disable ipv6 on the server itself. This has little to do with the AAAA record, as that would be for incomming connections!
You may have to contact your server provider on how to disable ipv6 (network wise) on the server. Just to get ipv6 issues out of the way first. Ipv4 is totally sufficient anyways for the moment, so best to get those potential issues out of the way.

Not completely following the video, but you seem to be using the same login sessions and from the video it is not too clear to me which tab is for which session and which user. Note that OpenID has a login session but also apps, depending on how they have implemented this, may have their own login sessions on top. It is sometimes confusing if the same browser is used with just different tabs....

Seems like mysql itself started fine according to those logs. Where exactly is your Cloudron hanging at the moment?

Manual intervention due to the major package version update. This means the app does not automatically update.
The DNS setup will work according to how the domain is configured, so of course if an automated backend is used, this will handle the actual DNS setup.

New app package with the API endpoint enabled is out. This is a major version update, so requires manual intervention as a new api endpoint subdomain is now required.

Update is blocked by https://github.com/LycheeOrg/Lychee/discussions/3189

Trilium stores its data in a sqlite database file. If you open a webterminal into the app, can you check the db file with:

file /app/data/document.db

it should print something like:

/app/data/document.db: SQLite 3.x database, last written using SQLite version 3042000, writer version 2, read version 2, file counter 1, database pages 1, cookie 0, schema 0, unknown 0 encoding, version-valid-for 1

We managed to fixup the machine learning and the new package is out.

@mmtrade we only provide best-effort support through the forum. If you need more timely and direct support, we have a subscription plan for this.

Overall we might have been too excited about the app without vetting the selfhosting state of upstream properly.

I only recognized the bitwarden issue, since I am seeing the same

Those errors come from a webextension you have installed in your browser. It does look like bitwarden (which has a bug with latest release, which looks like that) So this has nothing to do with the logout.

Do you even see any network requests happening on logout? If not please report this upstream, who knows maybe they haven't even implemented it.

Du to high amounts of spam, we require each new user to get manually approved by us. This happens with the first post, so in your case this one. So welcome here

The app is using a sqlite database file. Maybe that somehow got corrupted on disk. If you restore the app, does it work again?

Could also have just been a DNS propagation issue itself on the original (sub)domain. Hard to debug now, but either way, glad it worked out.

If you want to manage the Wekan users on your own, then you have to install the app without using the Cloudron usermanagement first. This is an app install only option, so you have to reinstall the app first.

Did you install Wekan with or without Cloudron usermanagement?

Since you are trying to create a new user, maybe user registration setting is disabled in your Wekan instance? I am just guessing though.

All in all, this question is probably not related to the Cloudron package but maybe worth asking upstream with the wekan project instead.