Error response from daemon: invalid pool request: Pool overlaps with other one on this address space means the --subnet you gave docker network create collides with a subnet another Docker network already uses. List the subnets in use, pick a range that none of them covers, and create the network again.

Partial overlap counts too: a /25 inside an existing /24 was refused with the same message. A subnet next to the existing one, not inside it, worked.

The error

PS> docker network create --subnet 10.231.7.0/24 fix9-run-net-a
a9ff9fa34f63a1c7169e1b512a352d7cc4bbcad376883456ab57b4ac0b6ac5ab

PS> docker network create --subnet 10.231.7.0/24 fix9-run-net-b
Error response from daemon: invalid pool request: Pool overlaps with other one on this address space

PS> docker network create --subnet 10.231.7.128/25 fix9-run-net-c
Error response from daemon: invalid pool request: Pool overlaps with other one on this address space

Why it happens

Each Docker network owns its subnet. The first command took 10.231.7.0/24, the addresses 10.231.7.0 to 10.231.7.255. The second asked for the same range and the third for its upper half, 10.231.7.128 to 10.231.7.255, so both overlapped the first network and the engine refused them. The name of the network that holds the range is not in the message, so you have to look it up.

No container was attached to the first network, and it still held its range: an empty, forgotten network is enough to block a subnet.

The fix

List every network with its subnet (read only):

PS> docker network ls --format "{{.Name}}" | ForEach-Object { docker network inspect $_ --format "{{.Name}} {{range .IPAM.Config}}{{.Subnet}} {{end}}" }
bridge 172.17.0.0/16
...
PS> docker network inspect fix9-run-net-a --format "{{.Name}} {{range .IPAM.Config}}{{.Subnet}}{{end}}"
fix9-run-net-a 10.231.7.0/24

The list above was taken before the first network was created; the other networks on the machine used 172.x ranges and are left out here. With the owner of 10.231.7.0/24 found, a free range worked: 

PS> docker network create --subnet 10.231.8.0/24 fix9-run-net-b
a4ec350c64f8d2219307c532a990942dd5feba8d19e36fd3554bbb97aef834d2

PS> docker network inspect fix9-run-net-b --format "{{.Name}} {{range .IPAM.Config}}{{.Subnet}}{{end}}"
fix9-run-net-b 10.231.8.0/24

The other way out is to remove the network that holds the range, with docker network rm, if it is yours and nothing uses it. If you do not need a fixed subnet, leave out --subnet and let Docker choose one; a test network created that way got 172.20.0.0/16, the next 172.x range after the ones in use.

How it was reproduced

On Windows 11 with Docker Desktop, engine and client 29.9.3, from Windows PowerShell 5.1. The existing networks' subnets were listed first, read only; then the test created fix9-run-net-a on 10.231.7.0/24 and tried the same range and a /25 inside it under other names. Both were refused; 10.231.8.0/24 was accepted. The network names and ranges are the test's own and both networks were removed.

Frequently asked

How do I see which subnets my Docker networks use?
List the names with docker network ls and run docker network inspect on each with a format that prints .IPAM.Config and .Subnet. The fix section shows the PowerShell loop as it was run.
Does a smaller subnet inside an existing one also overlap?
Yes. In this test 10.231.7.128/25 was refused with the same message because 10.231.7.0/24 already belonged to another network.
Do I need --subnet at all?
Only when something depends on fixed addresses. In this test a network created without --subnet got the free range 172.20.0.0/16.

More decoded errors in the Fixes category. A related network message, from a network that no longer exists: network not found.