Cloudron Forum

OK, this got sorted out on support. Basically, the configs got lost somehow. Putting back the vanilla configs from the package brings them back.

@nebulon Thanks, that worked a treat. I had tried 443 as the port previously, but that didn't work possibly because I didn't use 'https' in the url. Port 2283 was specified on the Immich Github page.

i can confirm that the order of the steps @onlybro describes work to enable video posting. so i guess including the config line by default as @robi suggests, would make it work for everyone?

@subven Huh, so it is. That was weird for me, I scrolled up and down and even typed in the name, before asking you here. But now I can see it easily and clearly. Strange. Thank you!

@lucidfox rsync + encryption has file path length limitations i.e if your app has a file which has long path (not just the file name, maybe it is some 10 folders deep) the backup will error. The limitations are documented here https://docs.cloudron.io/backups/#encryption .

@Robin opened a feature request here to improve this - https://forum.cloudron.io/topic/3057/consider-improvements-to-the-backup-experience-to-support-long-filenames-directory-names

That does seem to make sense. I just wanted to mention the second instance, as the default port wasn't an option.

Yeah, I was hoping to get a picture of the storage used by a user or usergroup across all apps on Cloudron. Apart from companies or single user installs of Cloudron, the thinking was that enabling groups of people to share a server and switch to self hosted open source
software would involve having insight into the main variable resource - the storage - in order for the cost sharing to be transparent.

I understand that's it's not feasible to implement, so will need to think of other community models for resource sharing. Mounting a users own NFS storage is an option, but Cloudron apps are restricted to a single storage location per app instance. Perhaps users mounting their own external storage in an app like Nextcloud is an option.

Any thoughts on a clean model for this kind of resource sharing scenario? This seems to me an important consideration for "regular" users of Cloudron, who might want to get together in order to make switching over from Google etc. financially viable.

Never used Git, will keep that in mind for reporting any issues that I might come across with Cloudron apps!

Now that I know that shared volumes is what I'm after 😜 (I thought it might be different somehow if it was a specific permission for an app to read data outside of it's docker container), how can I set up and use a shared volume if it's not exposed on the interface? Or is this something that's not trivial and best left alone till it's stably implemented?