Cloudron Forum

thanks @james. ok, so MEDIA_ROOT is like metadata and MUSIC_DIRECTORY_PATH is the real music. .

@AdMo said: Mar 04 11:44:53 box:services Backing up redis Mar 04 11:44:58 box:services pipeRequestToFile: timeout - connect or post-connect idle timeout Most likely redis is not running or needs more memory. Go to services -> redis . Edit it and give it much more memory. That should most likely fix it.

Hey, Tim! Thanks for looking. Why 4.2.0? Looking back, it is what the TinaCMS self-hosted starter's Dockerfile used, and we didn't think to question it until we were deep in ESM hell. We ended up having to install Node 22 via n and nuke the base image's Node 18, which is exactly the kind of thing a newer base image would have avoided. If 5.0.0 ships with Node 20+ that alone would eliminate Showstopper #5 (the ESM compatibility hydra that ate most of our time). The repo: Here it is: https://github.com/OrcVole/tinacms-cloudron Fair warning: it's in a "works up to the last mile" state. The Docker image builds, health checks pass, admin UI loads, auth works, and the GraphQL API returns JSON. But schema indexing into MongoDB never completes, so the editor can't actually load content. If someone familiar with TinaCMS internals (or Cloudron base 5.0.0) wants to take a crack at that final piece, the groundwork is all there. Would switching to base 5.0.0 and its native Node fix the indexing step too? That's the bit we never got past. The tinacms build --skip-cloud-checks command (without --skip-indexing) just prints "The service was stopped / Unable to build" with no useful error output.

@Joseph Despite my few years on Cloudron and packaging some apps, I have never used the demo server ! Embarrassing. Must try harder. So much more to know about Cloudron, so little time, such small brain.

@robi thank you May not help others, but does help me. Struggled a bit with SKILL for Nanobot, worked, then didn't, but now working correctly.

@sponch maybe you can enable remote ssh support for us and send a mail with the Cloudron's ip to support@cloudron.io I can then locally apply the patch to give collabora all those system permissions and we can evaluate if that is the root issue in the first place. FYI to test this one can add the following at https://git.cloudron.io/platform/box/-/blob/master/src/docker.js?ref_type=heads#L731 : containerOptions.HostConfig.CapAdd.push('SYS_ADMIN'); containerOptions.HostConfig.CapAdd.push('SYS_CHROOT'); containerOptions.HostConfig.CapAdd.push('FOWNER'); containerOptions.HostConfig.CapAdd.push('CHOWN'); Then systemctl restart box for good measure and then reinstall collabora in the same domain, as it is anyways stateless

@james Quick update — I just shipped a full Cloudron-native refresh of ISOMan (v0.3.8). This version is now properly aligned with Cloudron expectations and based on a cleaner packaging approach. Key updates: • Cloudron packaging aligned for production: proxyAuth + LDAP addons, persistent /app/data, internal port 8080, and healthcheck at /api/health. • Added optional create-only protection for POST /api/isos with LDAP-first authentication (Basic fallback still supported). • Fixed frontend create-flow issues when auth challenges returned HTML/non-JSON responses. • Added credential prompt handling for create-only auth and improved dialog accessibility. • Updated app icon handling for Cloudron login compatibility (PNG). • Deployment docs refreshed and fully translated to English. Result: Global access control remains managed by Cloudron proxyAuth, while ISO creation can now be protected independently without breaking the normal read/list UX. 0084e5c9-7ebf-440e-8746-d338bd190680-image.jpeg

@jdaviescoates https://forum.cloudron.io/topic/14339/nextcloud-update-pushed-too-early/22?_=1772614821048

Love to see this App in Cloudron ️

Hello @ikalou and @andreasdueren This is a known issue. I have merged your new topic into this existing one. Scroll up to find the solution and description of this issue.