New installation: can't install applications

[iamwillbar]

I have a new installation of Cloudron on Ubuntu 24.04, and when I attempt to install new applications they never complete installation. I have tried restarting.

The Docker logs show:

Jul 21 01:30:44 cr dockerd[944]: time="2024-07-21T01:30:44.673387498Z" level=info msg="detected 127.0.0.53 nameserver, assuming systemd-resolved, so using resolv.conf: /run/systemd/resolve/resolv.conf"
Jul 21 01:30:44 cr dockerd[944]: time="2024-07-21T01:30:44.861431480Z" level=info msg="[graphdriver] trying configured driver: overlay2"
Jul 21 01:30:45 cr dockerd[944]: time="2024-07-21T01:30:45.400298750Z" level=info msg="Loading containers: start."
Jul 21 01:30:45 cr dockerd[944]: time="2024-07-21T01:30:45.769177511Z" level=info msg="Default bridge (docker0) is assigned with an IP address 172.18.0.0/16. Daemon option --bip can be used to set a preferred IP address"
Jul 21 01:30:45 cr dockerd[944]: time="2024-07-21T01:30:45.832595505Z" level=info msg="Loading containers: done."
Jul 21 01:30:45 cr dockerd[944]: time="2024-07-21T01:30:45.880223201Z" level=info msg="Docker daemon" commit=60b9add containerd-snapshotter=false storage-driver=overlay2 version=26.0.1
Jul 21 01:30:45 cr dockerd[944]: time="2024-07-21T01:30:45.883013205Z" level=info msg="Daemon has completed initialization"
Jul 21 01:30:45 cr systemd[1]: Started docker.service - Docker Application Container Engine.
Jul 21 01:30:45 cr dockerd[944]: time="2024-07-21T01:30:45.931928378Z" level=info msg="API listen on /run/docker.sock"
Jul 21 01:30:50 cr dockerd[944]: time="2024-07-21T01:30:50.336803412Z" level=error msg="Handler for POST /v1.45/networks/create returned error: failed to allocate gateway (172.18.0.1): Address already in use" spanID=9539cda95085bd78 traceID=33f55372423a3ed512e42f6495c21add

[joseph]

@iamwillbar said in New installation: can't install applications:

Jul 21 01:30:50 cr dockerd[944]: time="2024-07-21T01:30:50.336803412Z" level=error msg="Handler for POST /v1.45/networks/create returned error: failed to allocate gateway (172.18.0.1): Address already in use" spanID=9539cda95085bd78 traceID=33f55372423a3ed512e42f6495c21add

Cloudron creates a docker network at 172.18.x.x . It says this network is already in use. Do you have something else running there?

[iamwillbar]

Not on 172.18.x.x, but I do on 172.17.x.x. I edited the systemd configuration and added --bip 192.168.1.1/24 as recommended in one of the other posts and that seemed to solve the problem. Will that be supported, or will I run into other issues?

[nebulon]

Generally anything which is not installed through Cloudron is not supported and will likely break with a future Cloudron update. The platform is designed to essentially own the host system to reduce potential side-effects from edge-cases which we cannot realistically test.

[iamwillbar]

That makes sense, but the assumption that an existing network doesn't use a specific IP range is a challenging one. It would not be easy, not should I have to, move hundreds of devices to a new IP range because Cloudron assumes that range is unused.

[nebulon]

Ah so you mean that the server is operating in a private network (hence the 172.... ipv4 range) which collides here? This is not about using that range on the same server on a loopback interface?

[girish]

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.

[iamwillbar]

@nebulon that's correct, the server is on a 172.17.x.x address. Cloudron's private network must use a netmask larger than /24?

[girish]

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.