Cloudron Forum

Thank you @girish , this worked. For those coming through in the future note that cloudron-support may ask you to reboot and run again, keep an eye out for it.

Hi Girish, First, thank you for taking the time to provide such a detailed and technical explanation. I genuinely appreciate it, as I find it very insightful. As I mentioned in an earlier post, the TMP directory that fills up the most is indeed Emby's because we move a lot of data there. We add a substantial amount of content regularly. However, it's not just Emby that has this issue. Several other applications also exhibit similar behavior. The list of these applications, which I posted earlier, includes: Emby N8N Cal Uptime Kuma OpenWebUI Penpot And a few other unidentified applications This list is not exhaustive, but these are the primary culprits. To answer your questions: a) Yes, the directory that had around 83GB of data was indeed Emby's TMP directory. This directory fills up quickly as we add more content. However, other applications also contribute to the storage issue, just not at the same scale as Emby. b) I add files to Emby using the File Manager. We do not use Emby's upload feature, even though we have an Emby Premiere instance. We prefer to manage our files directly through Cloudron because we trust its infrastructure and prefer to use it as intended. I understand that the issue is not inherently with Cloudron itself. My reflection was that this docker-volume issue only started appearing after I added a new storage volume to my server. To clarify, I added an OVH NAS-HA as a new volume to the server, and then I mounted it on Cloudron through the admin panel. This docker-volume did not exist, or at least was not noticeable, before this addition. Since moving Emby to the new volume, I see my data on the new volume as expected, but it also appears to be duplicated in the TMP directory on the server's disk. This duplication was not happening before the new volume was added. Hence, my hypothesis is that there might be a configuration that wasn't fully adjusted to accommodate the new volume, causing files to be stored in both locations. I'm not entirely sure how the backend works, so these are just observations and hypotheses based on my use of Cloudron.

@simong said in Support for docker compose: @ekevu123 I would recommend to use dokploy.com if you do not need the additional features of coolify. I have just tried dokploy and I like it a lot for docker compose setups. It was super simple to use and much easier than dockge or coolify. I might run potentially one server with cloudron and one with dokploy, so that I can cover all kinds of deployments.

@freetommy most likely the container needs to be re-pulled. If you go to Repair view, does it let you enable Recovery Mode? If so, enable recovery mode and afterwards disable it (this is a hack to repull the docker image).

@andreasb you can check the sizes of docker images here - https://hub.docker.com/u/cloudron . But looks like it lists only the compressed size. Size of docker images is not documented anywhere . The 6GB includes many layers and the layers are "shared" across apps (the way docker works). We also hvae images on quay - https://quay.io/organization/cloudron . But I think this requires login, despite images being public . These sizes differ from dockerhub [image: 1747727630514-d133353a-28be-41af-87eb-f9806443b9b9-image-resized.png] [image: 1747727643538-435fe29e-0a7f-4135-9c28-7e1481c34c6f-image-resized.png]

Closed due to inactivity

It seems the options --storage-driver=overlay2 makes docker unable to start when the data-root is on a mounted through sftp : adding it through the following error at startup failed to mount overlay: invalid argument storage-driver=overlay2 if I use it with a regular data-root, no errors show up. I guess we should conclude that this makes cloudron not compatible with sftp drive for storing docker images.

Thanks again, and for sharing the details!

Tyvm, saved my day!

Maybe you have dangling images around, which are not deleted, can you see if docker image prune -a removes some?

Tyvm, saved my day!

@girish I recall you making that run automatically.. Should it run more frequently?

@Neluser Good idea. But it's quite complicated to automate things like this, that's what it's not done. But something to keep in mind. In the meantime, following https://docs.cloudron.io/storage/#docker-images is the way to go.

The validation code seems to be at https://github.com/hay-kot/mealie/blob/8d79773bf65eb6bfd9021963324d53a25aab3cde/mealie/routes/admin/admin_about.py#L62 however I don't quite understand what it tries to check here. I don't think this is relevant on Cloudron though.

Also, in Cloudron 7.3.x, all the addons/services are still using the old base image (3.2.0) but the apps have all been updated now to use the new base image (4.0.0) . In 7.4, all the addon docker images are updated to 4.0.0. You will see some space savings after the update.

@hovinen Ah yes! docker returns 404 it seems when it doesn't have enough disk space to store images. I remember this (again) now. Unfortunately, the API has no way of detecting this.

@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

See https://forum.cloudron.io/topic/8101/fix-for-kernel-bug-in-ubuntu-20-04-causing-various-issues for a solution.