failed to allocate gateway (CONTAINER_IP): Address already in use

TL;DR: Something on the host already owns the .1 gateway address docker wants. Either free that address on the host or create the network with an explicit --gateway on a free IP. This usually means a stale docker network or a host interface squatting in the same subnet.

The error

failed to allocate gateway (CONTAINER_IP): Address already in use

Fix it

1. Find what holds the address: ip addr | grep CONTAINER_IP Expected: an interface (often a leftover docker bridge like br-xxxx).

2. If it is a stale docker interface, remove the orphan network: docker network ls and docker network rm [stale] Expected: the interface disappears.

3. Or sidestep with an explicit gateway: docker network create --subnet CONTAINER_IP/24 --gateway CONTAINER_IP mynet Expected: network created.

When this applies

• Network creation failing on the gateway allocation step
• Hosts where docker networks were deleted without cleanup

When this does NOT apply

• "Pool overlaps" (subnet-level conflict, earlier check)
• Port "address already in use" (different resource)

Versions

All Docker Engine versions.

Why it happens

The daemon assigns the subnet's .1 address as the bridge gateway. If a previous network's bridge interface was not torn down, or a host process bound that IP, the allocation fails even though the subnet itself looked free.

Edge cases

• ip link delete br-xxxx type bridge removes a truly orphaned bridge interface when no docker network claims it, but be sure it is orphaned first.
• Restarting the daemon cleans up most stale interfaces automatically.
• VPNs that grab CONTAINER_IP on connect cause this intermittently; create networks with explicit subnets outside the VPN range.

Asked: how to fix failed to allocate gateway (CONTAINER_IP): Address already in use. Verified answer: Fixes 'failed to allocate gateway ... Address already in use' when creating docker networks. Use when the default gateway IP of a new bridge network collides with something on the host. The fix steps above were cross-checked against the accepted community answer at https://github.com/pharkie/arr-stack-ugreennas/issues/10 (gh:pharkie/arr-stack-ugreennas#10), which confirms the same resolution.