Most people install Docker and never think twice about how it manages networks. Containers spin up, connect to each other, and everything seems to work perfectly. But Docker’s defaults hide a quiet problem that can break your setup over time.
Every time Docker creates a network, it reserves a large block of IP addresses from a shared pool. Eventually that pool either overlaps with your home network or runs out entirely, triggering the dreaded “could not find an available, non-overlapping IPv4 address pool” error.
The fix is simple, but it is something every self-hoster should do before it becomes a problem.
When Docker Uses Too Much Space
By default, Docker uses the address range 172.16.0.0 through 172.31.255.255, which is known as a twelve block. Each time a new network is created, Docker takes a large portion of that space, known as a twenty subnet. That means every new network gets more than four thousand usable IP addresses even if it only needs a few.
Over time, as you add and remove containers or create new stacks, Docker continues to reserve those large subnets. Once it runs low on space in the original range, it begins using addresses from 192.168.0.0, which many home networks already depend on. This can lead to IP conflicts and strange problems that seem to appear for no reason at all.
You might suddenly lose access to your NAS, or your router might start acting up because Docker assigned an overlapping address. It can be confusing and frustrating to troubleshoot if you do not know what is happening.
The “Not Enough Networks” Error
If you ever see an error like
"could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network"
That is Docker telling you it has completely run out of usable subnets from its default pool. It has tried to create a new network but every possible address range it knows about is already in use or overlaps with something else.
This error is common when Docker keeps carving large twenty subnets out of its twelve block. Eventually there is no room left. Adjusting the pool size fixes this completely.
The Simple Fix
There is an easy way to stop all of this from happening. The goal is to tell Docker to take smaller pieces of the same address range so it does not consume unnecessary space. Instead of reserving a twenty subnet each time, you can change it to use a twenty-four subnet. That change means Docker still uses the same twelve range, but it only takes smaller slices with about two hundred fifty-four usable addresses per network.
To make the adjustment, open or create the file /etc/docker/daemon.json and add the following configuration:
{
"log-level": "warn",
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "5"
},
"default-address-pools": [
{
"base": "172.16.0.0/12",
"size": 24
}
]
}Save the file and restart Docker. Then take down any active compose stacks and bring them up again so their networks are recreated using the new subnet size.
Once you have done this, Docker will still use the same twelve address block, but instead of handing out a large twenty every time, it will now allocate smaller and more reasonable twenty-four networks.
This change also fixes the “not enough networks” error. By resetting the address pool, you give Docker fresh room to create new networks without conflict. If you have already hit that error, prune unused networks with
docker network prunethen restart the service. After that, everything will work normally again.
Final Notes and Thoughts
Docker is powerful, but its defaults were never meant for a small home server. Changing the address pool once saves you from those strange network bugs that always show up at the worst time. It keeps Docker in its own lane and lets the rest of your setup run without surprise conflicts.
It is one of those fixes that feels minor but makes a big difference. You do it once, forget about it, and everything just works the way it should.
Jeremy
Discussion