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

@girish I've never changed backup method no there should not be any remains from that. I did have a directory from april sitting around at 8.6 GB though 😁.

Removing that still leaves Other quite large though, so I'll appreciate more hints if you have any.

@nebulon Hi. Yes, indeed, the instance has 20gb. I deleted files from trash in Nextcloud and got back to normal with 6gb of free space.

Thank you @nebulon for solving this issue off-forums.

For future reference: problem was caused by the external storage being unmounted after a reboot. Remounting the storage drive (I use a netcup VPS) and then repairing in the Cloudron dashboard solved the problem. Including the mounting in /etc/fstab solved this issue for following updates/reboots.

We have wasabi support coming up in the next release.

This was resolved offline - most issues where related to unbound (the internal DNS server) being down. Fixed by System -> restart unbound.

@doomilation Yes, what you have done should work. You don't have to move out appsdata and platformdata.

@nebulon Okay. Thanks for clarification!