Cloudron Forum

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

I get this: docker inspect 5130e1789e1e | grep Memory "Memory": 5368709120, "MemoryReservation": 0, "MemorySwap": -1, "MemorySwappiness": null,

@nebulon I will build up real experience and report here

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.

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