Cloudron Forum

Maybe https://forum.cloudron.io/topic/1579/var-lib-docker-overlay2-getting-full?_=1760112116784 is helpful: @nebulon said in /var/lib/docker/overlay2 getting full: For a start, docker images are often quite large, composed of a multitude of filesystem layers on top of each other. To mitigate the problem a bit, all Cloudron apps share the same base image, that helps a bit. The appsdata folder really only contains the data from within the apps, so that heavily depends on your own usage. The application code, so to speak, is inside those docker images.

@robi I only added the recommended commands: 0 13,23 * * * rm -rf /app/data/public/wp-content/cache/* > /dev/null 2>&1 0 13,23 * * * rm -rf /tmp/magick-* /tmp/imagick* > /dev/null 2>&1

Ok if I switch it to "Direct disk" it fails to boot but "GRUB (Legacy)" kernel option seems to boot fine.

Hello @mbarria Since there was no more update in this topic can I assume this resolved itself?

Just a quick update, since I am using this since March. I didn't had any issues with that kind of storage usage for the Docker during normal operations. As I didn't have an situation with restore or bare metal recovery, I still don't have any experience for these use cases. So far, I am pretty happy to offload the Docker Images to the Hetzner Volume.

Thanks @girish for the changes in the docs and letting me know. I will take a look as soon as the time allows and may get back to this topic at a later date.

A homemade problem. We have refactored our Ansible role. It has installed an MTA that was previously started as Cloudron's mail service. After uninstalling the MTA, everything works as expected.

Yes that is handled by app package updates. We usually stay as close to what the upstream app recommends. Through the containerization, we can have different php (and other languages/framework/library) versions on the same system, depending on the individual app. This also means if you find a package using a wrong or by now outdated version, please let us know in that app section in the forum and we will see if and how to update those accordingly.

Hi @joseph pandoc is also part of Cloudron n8n package You're right I didn't realize this. It is a good surprise. I have other workflow requiring GDAL binaries for example (https://gdal.org/en/latest/). This one is mode specific and is not here. I guess I am good to make a custom packaging... I found some shady npm packages including binaries but it does not seem properly maintained.

I think we have to go back to the original question. What's the original issue? Using tools like df in /var/lib/docker/overlay2 won't work.

@joseph , Running 'cloudron-support --recreate-containers' fixed the issue. Thank you.

Happens a LOT I don't mind at all.

Fixed in https://git.cloudron.io/cloudron/box/-/commit/abf445e96949ab952c07b457610a1a890cf4e339 for next release.

@timconsidine thanks, I have added a validation check now.

Yes, /24 would only allow 250 or so addresses, we do need a /16 . I am not sure why 172.17 and 172.18 networks are conflicting though . In the original error message it says "172.18.0.1" is in use. If your local network is 172.18, it all makes sense. Currently, there is no workaround for this since the code has some places where it hardcodes 172.18 network.

Closed due to inactivity

Closed due to inactivity

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.