Cloudron Forum

@LoudLemur I think the answer is still to use Peertube, which is much more like "an Immich for videos" than Owncast is.

Owncast is designed specifically for live streams, not for what you are trying to do (if I've understood you correctly).

Note, Peertube also supports livestreaming. But it is specifically designed for uploading and sharing videos that people can watch at anytime.

Have a read of https://docs.joinpeertube.org/use-create-upload-video (that includes details about how to do either a one-off or recurrent/ permanent livestream and gives some examples of streamings using OBS or Jitsi)

@robi
On that, I don't have the data or experience to talk.
But 100% sure you can't use wasabi latency, I think smb or better NFS should be a better option, but I'm not an expert.
and Using so much ram for it, im not big fun about it, but I would have to try it before to have a real feedback

@jdaviescoates said in How to make Cloudron Immich keep its files in mounted block storage?:

@LoudLemur said in How to make Cloudron Immich keep its files in mounted block storage?:

I try the commands to create a volume,

what commands? where?

Thank you @jdaviescoates , you magic man! Thank you too, @nebulon for finding the time to look at my post.

As usual, Cloudron already had all the information I needed there.

My difficulty came from reading the output of the blkid command:

blkid

You are returned a UUID result along with a PARTUUID result, and I copy/pasted the wrong one.

Staring at the backup logs for a while, it dawned on me that it might be easy to extract the App sizes based on the data reported of what is uploaded ex: 48M@5Mps

Sounds easy to add all those up from a backup run and have a total backup size based on what was transferred in parts.

@ei8fdb

I delete the dump file, then decide to backup from that's date - restore will fail?

No, a copy a the postgresql file is in the backup. The file at /home/yellowtent/platformdata/<appid>/postgresqldump is a temporary file. When we want to backup an app, we create a dump from postgresql and save it to that file. Then we upload that file to wherever the backup is located . After the backup is done, that file has no real use but we just keep it around because in some rare cases where you don't have backups it can help in recovery.

So, to summarize:

Safe to delete /home/yellowtent/appsdata/app-container-id/postgresqldump . But this will be created as part of the backup process, so it's going to be a pain. You have to delete this file everyday. Your final backup location will have a copy of the above file. Under <timestamp>/appid/postgresqldump . This is your backup, don't delete this file!

@jodumont No, nextcloud has a completely different install mode which is S3 only for everything.

@nebulon said in where is going my hardrive space ?:

Note that stopped apps still take up the same disk space as running apps.

Yes that I'm aware of 🙂

32a82917-130e-44e8-88a9-70d6d9574030-image.png

So I clean up few apps and extend the drive
3c5e9f4e-bd4f-4d62-81ec-f2104e72387c-image.png

@nebulon said in where is going my hardrive space ?:

The du command does not calculate the correct usage for the docker volumes/mounts.

Definitely du don't play well with overlay

@jodumont yes. Samba is the only protocol on your list that is really made to be mounted locally. Personally I would try to avoid having to rely on php for access to remote filesystems (regardless of the protocol).

@girish thank you for the insight. If I am extending the existing drive then I'll make sure to keep it SSD as it already is, I may try HDD if going the first route though. I'll check, this isn't an easy task for extending the existing disk unfortunately, but this may be the better move. Of course the drawback there I guess is I'll be paying for way too much disk space and need to do it all over again if I for example lose one of the clients that are using so much email space (as email is the single biggest consumer on my server right now, by a lot). I'll have to run some tests. 🙂

@girish Thank you for your world-class customer support! Sending blessing! ☘️⭐️💎

Hey guys, sorry for the delay

I've updated the fork and the providers function, if I get permission to create a new branch or you open one I can open an MR with the new branch and let you review

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.

@ice The Cloudron disk graphs is computed only twice a day. So, please check after atleast 12 hours of the disk resize.

@smilebasti The /home/yellowtent/appsdata is the location of apps. This size seems to roughly match the nextcloud size. As for docker, you should not use du tools inside docker's image directories since they are overlays and the du tool is not smart enough to figure out the size correctly. Try docker system df to get a better idea about the actual size docker uses (this is what is reported in the graph as ~5GB). The volumes also link into appsdata so they might be double counted the du tools.

To take a wild guess, maybe you were backing up to the file system for some time before you moved to NAS via SMB? If this was the case, then you should remove the old backups manually from /var/backups. You can just safely nuke all the timestamped directories and the snapshot directory inside it.

@girish Ah interesting, yes that definitely seems like an OVH-specific issue then. At least they're heading in the right direction I guess towards the end of this year. 🙂 Thanks for shedding some light on that one for me.

@seeker Ah, I see. I think you can actually use minio for this because it looks like you just want file storage? All the standard S3 modules will work with minio and it's very easy to integrate.

@girish Oops, I realized just now, that I didn't reply to your question yet. What I changed and maybe has to be protected from being accidentally overwritten is the 'datadirectory' option in /app/data/config/config.php. I changed that path from the default path to '/media/mymountpoint'.

I don't remember if I had Nextcloud in maintenance mode or put the app in recovery mode, while I changed that path and moved the files. But it was either of them. However, I had some duplicate storage paths in the database afterwards and I manually updated the oc_storages table as described here and did a files:scan afterwards. But that should not be related to what the code for updates overwrites, I guess.

For future reference, you have to use resize2fs to grow the ext4 partition when you expand the disk size. This is atleast the case for most public cloud block storage and is a manual operation. Cloudron could potentially do this but I am guessing there is a good reason to not do this automatically, otherwise public cloud folks would have done this already 🙂

Thanks, investigating this. I suspect the node module is unable to parse the output because of something in the output. I will keep you posted here.