Cloudron Forum

Just so we talk about the same thing... Cloudron has an internal network 172.18.0.0/16 . These IPs never leave the server. It's only a problem if your own internal network is also using these IPs. Is that the case? Generally, the docker stack uses 172.17 or 172.18 and the private networks use 192.168 (home) or 10.0 (enterprise). Very broad generalization yes.

I do know that the train network here (DB) uses 172 and it conflicts with Cloudron's network... It's kind of annoying when connecting to their wifi.

@RichardsGee can you SSH into your server and try docker pull cloudron/io.n8n.cloudronapp:20240704-114058-87339b311 ? The image is correct and valid - https://hub.docker.com/layers/cloudron/io.n8n.cloudronapp/20240704-114058-87339b311/images/sha256-524b389f3b533b2245b57489dc13761e90fd2dcad06b3b8fdcd5af0b32ac966d?context=explore

Actually docker pull ubuntu is just a test pulling a random common image. This is not required for Cloudron. I was just trying to rule out some issues.

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.

@ekevu123 good input. Something for us to keep in mind for future planning. I didn't mean to rule the feature out completely, just that it's quite a different kind of feature than what we are doing now. I definitely see the potential.

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

@d19dotca it seems the yarn cache was note cleared. Clearing it brought down the size . It's in the new package.

@chaitanya it seems there is some networking issue connecting to dockerhub . Can you try pulling down some random docker image?

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.