Cloudron Forum

I have a lot of hw to do regarding app permissions, specifically Google app permissions. Knowing myself, I'll shoot myself in the foot and give Google more permission than needed, rendering the whole GOS setup moot

@superhua good to verify. Find an issue upstream or file one?

Viva la LLM: The container is healthy now — 1 running, 0 unresponsive. The Cloudron update worked: - New image: cloudron/com.nextcloud.cloudronapp:202607231345050000 - Nextcloud: 34.0.2 (up from 34.0.1) - user_oidc: 8.10.1 — working! How extensions should be updated in Nextcloud under Cloudron The proper way is: 1. occ app:update — updates from Nextcloud app store to /app/data/apps/ (persistent across restarts) 2. Nextcloud web UI → Apps — same effect 3. Cloudron app package update — what you just did; the vendor bundles newer versions in the image The root issue was that the old image (202606251555380000) bundled user_oidc 8.3.0 which had max-version="33" — incompatible with Nextcloud 34. The startup script's $occ user_oidc:provider command couldn't register. The data volume still had our manually-installed 8.10.1 from earlier. The new image (202607231345050000) likely bundles a compatible version, or my 8.10.1 on the data volume is now taking effect.

@SansGuidon said: I wonder anyway how it happened to break for some users only? My guess: the non effected users app had enough RAM to successfully complete the migration

Migration update: guided one-command Synapse → ESS wizard in v0.3.17 The migration workflow has now been wrapped in an interactive wizard. After installing a fresh ESS target on temporary domains, run this on a Mac or Linux computer where the Cloudron CLI is installed and logged in: bash <(curl -fsSL https://git.due.ren/andreas/cloudron-ess/-/raw/v0.3.17/scripts/cloudron-synapse-to-ess.sh) No migration arguments are required. The wizard asks for: the domain of the old Cloudron Synapse app; the primary domain of the fresh ESS target; rehearsal or final migration; explicit confirmation before starting; a second confirmation after the complete syn2mas dry-run. In final mode it freezes the old homeserver before the database dump, leaves both apps safely offline for the domain switch, and starts ESS only after the operator confirms CUTOVER-DONE. The wizard handles Cloudron backups, PostgreSQL export/restore, the original signing key and server name, appservice registrations, local media, S3 configuration, target recovery mode, preflight checks, the official syn2mas dry-run/import, and rollback. One important media detail: local media is copied even when S3 is enabled. S3 may have been enabled after older media was created, or an asynchronous upload may be incomplete. The migrated target therefore preserves the union of all local files and existing S3 objects instead of assuming the bucket is complete. I completed a real end-to-end rehearsal through the new no-argument terminal UI using a fresh disposable ESS target and an existing Cloudron Synapse database. It completed with exit code 0 and verified: 3,061 Synapse user rows and all 45 human users; matching imported human compatibility sessions; 29,533 local media files / 2,389,933,963 bytes; identical signing-key and S3-provider fingerprints; identical contents for both appservice registrations; successful read access to the existing S3 bucket; removal of credential-bearing staging data after success. The old homeserver stayed online throughout the rehearsal. The disposable target was kept in recovery mode, verified, then uninstalled. Only backups created by the test were marked for immediate expiry, and they have already been cleaned up. Documentation: Guided wizard: https://git.due.ren/andreas/cloudron-ess/-/blob/v0.3.17/scripts/cloudron-synapse-to-ess.md Full migration reference/manual fallback: https://git.due.ren/andreas/cloudron-ess/-/blob/v0.3.17/docs/MIGRATION.md The final production domain reassignment remains an explicit Cloudron dashboard step because legacy Synapse/Element domains and bare-domain well-known setups differ between installations. The wizard does not guess or silently take over domains.

@andreasdueren one line at a time didn't work nor pasting it whole. I pasted them one section at a time and that worked. The "export" lines were done one at a time though. But the "echo" ones had to be as one. e.g. echo "Checking for duplicate email templates..." psql "$CLOUDRON_POSTGRESQL_URL" -v ON_ERROR_STOP=1 -c " SELECT name, template_type, locale, account_id, inbox_id, COUNT(*) FROM email_templates GROUP BY name, template_type, locale, account_id, inbox_id HAVING COUNT(*) > 1; " This was pasted in one go.

@james said: I am not quite sure what "hidden" post you are referring to, sorry a little confused here. New user so my posts are/were hidden until "approved", it wasn't showing yet, thus "hidden".

Attention: I have made a few tweaks to my release pipeline and as a result of that the url of the CloudronVersions.json has changed. The shop listing has the updated url, but I don´t think there is an automated upgrade so the app needs to be removed and reinstalled.

yes that might be worth asking upstream at the app to maybe improve this UI for better usability and predictability.

@simon yeah, that makes sense. I think I will just cap it for all instances to 4.

Thanks @nebulon - Much appreciated.

Hello @christophermag Thanks for reporting the update resolved the issue.

Looks like Omniroute is the better choice and since @timconsidine already packaged it, use that instead. It's in the Community App store already.