-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error starting daemon: Error initializing network controller: list bridge addresses failed: no available network #123
Comments
This is a duplicate of the issue you opened in moby/moby#35121 (comment) - let me close this one as well, but feel free to continue the conversation in the linked issue |
Sorry, my mistake. I wanted to place this issue here but I was something bad clicked. |
ip link add name docker0 type bridge |
For interested parties- @kinglion811 's solution worked perfectly for me on Ubuntu 17.10 |
this woked for me |
Anyone else having issues to install docker on Ubuntu 18.04 by following the official docs should try this to fix it because it helped me fix my installation and start docker daemon. The error message could be very cryptic and show this ExecStart=/usr/bin/dockerd -H fd:// (code=exited, status=1/FAILURE) But after executing the binary manually you will see some errors like this Error starting daemon: Error initializing network controller: list bridge addresses failed: no available network And adding a docker0 bridge interface fixes the problems, like described above. Regards, |
This worked for me as well. Awesome. |
I was getting the exact same error. Turned out my kernel got updated, rebooting the system worked. |
why adding a docker0 bridge fixes the problems? |
+1 And why document does not include this |
this solution worked. fedora 30. |
/reopen |
had same issue ... no bridge and systemctl/journalctl report very cryptic on Debian 9.9 |
@kinglion811's solution worked on Ubuntu 18.04.3 LTS (bionic) - dual boot windows/ubuntu. Hours of searching for this one! |
We really need somebody to explain why @kinglion811's solution worked. To add, it worked for me. |
Had this same issue. @kinglion811 solution also wored for me on Ubuntu 18.04 but im curious as to why? |
had same issue ... the ip route table was misconfigured ip route
docker netutils.FindAvailableNetwork would failed with 'no available network' |
In my case I then fixed the pool |
Suggestion from @kinglion811 worked on Manjaro 19.0 as well |
It's not clear why this is closed if it still requires a solution (from so many people). Is this something that is not within docker's scope to fix? |
I was able to fix this error by making sure the IP address range I gave for the pool wasn't already claimed. This is likely the issue for anyone else encountering it, either a VPN, you router, some other bridge is claiming that IP address range, pick a different one and restart and you will hopefully find success as I did. The tricks mentioned above only gave temporary relief from the issue (creating a docker0 bridge manually) as soon as I restarted the service the errors returned again. So I don't recommend them. The most helpful command I ran was: I did delete all of my existing networks using the tricks above (get it working then delete) but I now wonder if that was necessary. |
I don't know that IP addresses can be "claimed". I am on Linux and for me the issue is that there is a route that routes 10.0.0.0/8 through a VPN. A subnet of it is available for use, but Docker refuses to use it because there is already a route there, but it's welcome to override it - except I can't tell it to do so. I think there should be an option for Docker to just go ahead and "claim" the IP addresses and add routes. If anybody knows of one I'd be interested to learn about it. |
Works for me. |
Had the same issue, applied @kinglion811 's magic and boom it worked. Could someone please explain, how exactly this fixes the issue? |
@Snagnar the default docker network is attempting to use an IP address range that are already used by another device on the network so it recognizes that and fails (because two devices can't have the same IP). The magic above changes the default network to use a different IP address range and then it works. Another solution people seem to be overlooking is what @ryanisn posted on this thread. It is a better solution to me as it uses dockers native config setup. Here are the docs: https://docs.docker.com/network/bridge/#configure-the-default-bridge-network |
@ToonSpinISAAC Why not pick another private IP address range like 192.168.x.x or 172.16.x.x? I very commonly use the 192 range for my routers, 10 range for my VPNs and 172 for my VM / docker setups. https://www.arin.net/reference/research/statistics/address_filters/ |
I have three answers to that:
This issue is super clear, at least from where I'm sitting: you can have Docker use a custom IP range but it refuses to use any of them in certain circumstances for no valid reason. It's a clearly a bug, and if I knew how to write Go I would have submitted a PR long ago. I've actually considered learning it for this reason. |
I would expect that even if you learned go and wrote a patch that allowed IP address ranges to conflict that it wouldn't get merged. And to give you my perspective, I am not a docker guru, I am not a networking guru. I am just a guy that spent tons of my person time learning basic networking principles in order to over come this specific issue on my personal setup not my corporate setup. So I was in your shoes a few months ago and am chiming in here because I know fighting through this error sucks if you don't have the knowledge to know what is happening here. If you really wanted to learn go and submit a patch, a good approach to solving this would be to have docker find an available ip address range if the assigned one is not available. |
@ccjjmartin, sorry but you are not right. 10.0.0.0/8 via 192.168.2.1 dev tap0 proto static metric 50 This should not be any problem because these routes are always least specific in RFC1918. { The daemon complains that it can not configure this because it can't create the bridge interface, but when I look at the routing on my local machine when the docker daemon is started before the VPN comes up, the routing for the docker daemon looks like this: This route is more specific then the routing pushed by the VPN, so it should never be a problem. The docker code should just create the bridge interface and the route and make the routing on the system sort it out. Jan Hugo Prins |
Hi @jhaprins, You said it better than I could. I would add (and I assume you will agree) that even if this is intended behavior, I disagree with Docker's philosophy because I feel provisioning IP ranges and preventing conflicts is not Docker's responsibility but the network admin's. I think that's a big difference between @ccjjmartin's point of view and ours. Edited to add that I want to be clear and I highly doubt that this behavior is what the Docker developers want. I don't think this is intended behavior. Chris, think of it this way: I think what me and Jan Hugo are saying, is that the point of having this setting in daemon.json is for users to tell Docker which IP ranges are safe to use, and not the other way around. I am capable of partitioning my own network, and want to be able to tell Docker where its sandbox is. It's none of Docker's business that the sandbox happens to be in a playground with other kids playing in other sandboxes. |
Hello, I have found an other reason why this must be a bug in the docker code. I should be able to split this route in my routing table, without any side effects into the following 2 routes: Before I do this split in my routing table docker start just fine with the following config: After this split the docker daemon fails to start with the following error: My complete routing table looks like this: Conclusion: Jan Hugo Prins |
I have found an open ticket in the moby project that matches this same error (also some closed tickets) and I have given a full explanation in this ticket why this should be treated as a bug: moby/moby#33925 |
thanks. Worked |
The
Note however that this is still a workaround. It SHOULD NOT be up to the user to set up the bridge interface required by an application! Docker should definitely take care of it automatically! And this is completely counter-intuitive if you look at the returned error:
What that error means is that ALL of those subnets should be tested, and Docker should pick the first available subnet if a network interface isn't available already and create a bridge on it. What happens, instead, is that if none of those subnets is already assigned to an available network bridge, and some of them are already in use from another interface, Docker fails, believing that for some reason NONE of those addresses is available. Can you guys please motivate how this is not supposed to be a bug? I'm appalled by the fact that after so many years and reports the development team hasn't yet addressed this issue, and the issue is still closed despite so many reports. Please address this, or at least motivate why this isn't a bug! |
In my opinion, none of the ranges should be tested if they are in daemon.json. Again, Docker needs to not tell me how to partition my network. Instead it needs to listen to me as a network administrator because I, not it, decides what IP ranges are available to it. |
I have linked open tickets with an exhausting analysis of this bug. |
This comment from @kinglion811 works! I'm running Ubuntu 20.04.02 LTS on Pine64.
Why doesn't I followed the installation guide mentioned here but doesn't work out of the box. I had to edit the I also followed @ryanisn 's comment above I also created a
NOTE: The above address ranges work for me - Others may try using this as-is, but if doesn't work (due to home LAN or VPN), you might need some trial-and-error. Adding this comment to help others who may have the same issue. And thanks to the great comments from @ToonSpinISAAC, @ccjjmartin, and @jhaprins - Perhaps Docker should force users to create the |
Niubility! this worked for me |
good |
With openconnect VPN I have a 172.16.0.0/255.240.0.0 route for him, so I had to apply @kinglion811 magical recipe (#123 (comment)) with the next available address: 172.32.0.1/16 More info on http://jodies.de/ipcalc?host=172.17.0.0&mask1=255.240.0.0&mask2= (see HostMax field) |
IT appears Docker currently is unable to fulltunnel in OpenVPN due to routes - as mentioned here several times, and this should be seriously worked upon? The solution is to get your admin to switch to splittunnel.
|
How and why? What do those command do, why does doing that thing solve this issue, how was it possible that a critically important part of system configuration just spontaneously "deconfigured" itself, and why isn't docker smart enough to reconfigure it for itself after finding it missing? |
Sol
This solution work in Ubuntu 22.04 |
Many thanks. |
I think moby/moby#43360 also addresses the situation with a VPN enabled (which is included on docker 20.10.15 and up) |
Thanks @thaJeztah , this really helped! I really had to switch to a different IP range -- due to office IP conflicts -- so this was a deal breaker for me! It was working in my machine, but not in my colleagues. I was worried if it was something at the OS level, but luckily that wasn't the case. |
Description
I have physical machine with Gentoo as host OS for Docker containers. I have compiled kernel using instructions on page https://wiki.gentoo.org/wiki/Docker#Kernel and I have installed Docker from Gentoo repository (see on the section Additional environment details (AWS, VirtualBox, physical, etc.)). I have set following USE flags:
I have emerged Docker and added it to boot level
default
in OpenRC init system. After compiling kernel and Docker I wanted to check if Docker is working so I typeddocker info
in terminal and I got error. I have decided to check what is wrong and I need your help with solving issue.Steps to reproduce the issue:
docker version
command.docker info
.Describe the results you received:
In the output of
docker version
(see below) you can see errorCannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
. The same message appears if I try get Docker system-wide informations. The same error appears if I try run the same command prepending by sudo, so this error applies to daemon. I tried to check if there a mistake in Docker daemon privileges. Based on these messages I am able to say that maybe Docker daemon not running. I checked daemon status to make sure. Docker daemon is crashed. To see the reason, I looked at the logs.Output of
cat /var/log/docker.log
:Describe the results you expected:
docker info
should return Docker system-wide informations instead ofCannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
.Expected output of
docker version
:Additional information you deem important (e.g. issue happens only occasionally):
Output of
docker version
:Output of
docker info
:Output of
sudo docker info
:Output of
sudo service docker status
:Additional environment details (AWS, VirtualBox, physical, etc.):
I am using Gentoo as Host OS for Docker containers. I have compiled kernel using instructions on page https://wiki.gentoo.org/wiki/Docker#Kernel and I have installed Docker from Gentoo repository.
Host system informations:
I have disabled iptables and ip6tables because firewall is not actually properly configured. I am connecting to internet through VPN and I am using 8.8.8.8 and 8.8.4.4 DNS providers. I have running Tor and Privoxy daemons and I am using OpenRC init system.
The text was updated successfully, but these errors were encountered: