@girish Thanks for the detailed response on the issues and limitations surrounding shared volumes. I'm basically just looking for anything that is an upgrade on SFTP and could be an easy way to store and access media across apps on Cloudron that support using shared volumes. And if possible to achieve this without disappearing down a trouble shooting rabbithole myself.

I would be happy to try using a volume that is shared between Jellyfin and Syncthing, if that's something that would work? Syncthing seems to have a good reputation for transferring larger files reliably, and has peformed pretty well on a few test I've tried.

I did read about the unreliability of Nextcloud external storage and issue with Lychee and creating it's own database (which I guess makes it a less desirable all purpose photo manager alternative to Google Photos).

I think it might be beneficial to have some stats or tracking mechanism for the server resource usage of users or usergroups in Cloudron, as this would enable non enterprise and multiple user servers to share hardware resources fairly The use case scenario here would be communities or groups of people who want to share, and spread the word on self hosting open source applications.

The biggest variable in my mind, in terms of calculating costs, is the amount of storage a user or usergroup uses. Is there someway to track this, so that a percentage share of storage provisioned can be worked out?

I've read elsewhere that Netdata might be the way to go, to get detailed info on server resource use. Would this work for seeing a Cloudron user's share of mounted NFS storage for instance? Or is this something that is better accomplished from inside specific apps, like say Nextcloud.

I recently got Cloudron running on a Netcup VPS with NFS storage mounted (also provided by Netcup). This works great for moving individual app data for most apps off the main server, but for the Jellyfin app the Docker containerization of data seems to stop there being anyway to actually get the media into the app? A shared volume that could be 'seen' by different apps would be ideal, and this would also be great for something like sharing photos between Nextcloud and Lychee. Is this a feature that is going to be rolled out soon? I read elsewhere that something like this was planned for an earlier Cloudron release.

I've been looking for possible work around using symlink or hardlinks, or mouting external storage in Nextcloud, but none of the options seem to really be viable. Rclone with a cloud provider seems to be a popular solution for Jellyfin, but I'm not sure how this would work? Any suggestions on a workaround that wouldn't break how Cloudron's backups and default behaviour works would be greatly appreciated. I have almost no experience with managing a server, so the less tinkering the better!

@mehdi Thanks! That worked a treat. Setting the right ffmpeg path fixed it and playback is working with and without the transcoding options disabled.

@girish thought I'd flag this for you. As having the ffmpeg path set up right by default, might be useful to make it more seamless for other noobs looking to run Jellyfin on Cloudron. Also, would it be possible to share folders between Syncthing and Jellyfin? Maybe this would be easier to achieve than more complex shared volumes?

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.

Anyone have any thoughts or ideas on this? Perhaps some kind of solution using syncthing?

@mehdi @jdaviescoates Thanks for the heads up on that. It sounds like it ticks a lot of the boxes. Will give it a go, and update how I get on here.

Update: It appears to be an instance of Syncthing with a particularly long filepath that is causing the backup issue.

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

@BrutalBirdie thanks for the links, i'll check them out. nextcloud was actually the app that was most critical to backup, so i did a manual backup of that and it worked fine.

@nebulon we do have encryption turned on, i'll try to turn it off to see if that helps. an encrypted backup would of course be more desirable but perhaps another non-s3 storage option would work better for this.

thanks for the tips. i'll do manual backups and check the logs to figure out which app or file is causing the snag.

Cloudron was backing up fine to Wasabi until 4 days ago, but it has been throwing up an error when attempting to upload a snapshot since then. This happens whether a manual backup is triggered, or it is run according to the backup schedule.

The region that this Cloudron instance (v.5.6.1) is being backed up to is Wasabi EU Central 1, and the storage format used is rsync.

The Error Message: Your key is too long HTTP Code: KeyTooLongError

I tried to change the API keys, but that didn't help. Manual created backups of individual app still seem to working fine. Any ideas on how to solve this?

@nebulon No, the port gets reset to the one defined on the Cloudron dashboard when restarting the app (and there is only 1 listener listed on Syncthing). But the connection to the syncthing instances on my other devices work fine after that, even though they didn't initially on that port.

Changing the Sync Protocol Listen Addresses in the Syncthing settings 'Connections' tab to 'default' seems to have done the trick.

I'm trying to run a second instance of Syncthing on a server (installed on another domain). I set the sync port in Cloudron to a non-standard port '22846' while setting up the second instance, but it just isn't able to connect to other devices. Is this because other ports apart from '22000' are blocked? In the app config page it says 'Port over which syncthing will exchange data (do not disable) (1024 - 65535)'

syncthing on my desktop reports these errors:
tcp://x.xx.xxx.xx:22846
No connection could be made because the target machine actively refused it
tcp://default:22846
no such host (11:15:21)

syncthing on cloudron reports this error:
tcp://xxx.xxx.xxx.xxx:22846
no route to host (11:18:17)

Any help figuring this out will be much appreciated. Thanks.

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.

I think it might be beneficial to have some stats or tracking mechanism for the server resource usage of users or usergroups in Cloudron, as this would enable non enterprise and multiple user servers to share hardware resources fairly The use case scenario here would be communities or groups of people who want to share, and spread the word on self hosting open source applications.

The biggest variable in my mind, in terms of calculating costs, is the amount of storage a user or usergroup uses. Is there someway to track this, so that a percentage share of storage provisioned can be worked out?

I've read elsewhere that Netdata might be the way to go, to get detailed info on server resource use. Would this work for seeing a Cloudron user's share of mounted NFS storage for instance? Or is this something that is better accomplished from inside specific apps, like say Nextcloud.

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?