@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 .
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?