Cloudron Forum

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.

The error doesn't appear anymore. Not sure why (cloudron updated to v8 meanwhile).

The errors remaining are "typical build image errors". Thanks for your support!

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.

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

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

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