My Docker Daemon seems to ignore /etc/docker/daemon.json on boot.

Similar to this question, I'm having some troubles telling the Docker daemon that it should not use the default 172.17.* range. That range is already claimed by our VPN and prevents people connected through that VPN from making a connection to the server Docker runs on.

The hugely annoying thing is that every time I reboot my server, Docker claims an IP from the VPN's range again, regardless of what I put in /etc/docker/daemon.json. I have to manually issue

# systemctl restart docker

directly after boot before people on the 172.17.* network can reach the server again.

This obviously gets forgotten quite often and leads to many problem tickets.

My /etc/docker/daemon.json looks like this:

 "default-address-pools": [
      "base": "",
      "size": 24

and is permissioned like so:

-rw-r--r--   1 root root   123 Dec  8 10:43 daemon.json

I have no idea how to even start diagnosing this problem; any ideas?

For completeness:

  • Ubuntu 18.04.5 LTS
  • Docker version 19.03.6, build 369ce74a3c

EDIT: output of systemctl cat docker:

# /lib/systemd/system/docker.service
Description=Docker Application Container Engine
After=network-online.target firewalld.service containerd.service

# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
ExecReload=/bin/kill -s HUP $MAINPID

# Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
# Both the old, and new location are accepted by systemd 229 and up, so using the old location
# to make them work for either version of systemd.

# Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
# Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
# this option work for either version of systemd.

# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.

# Comment TasksMax if your systemd version does not support it.
# Only systemd 226 and above support this option.

# set delegate yes so that systemd does not reset the cgroups of docker containers

# kill only the docker process, not all processes in the cgroup


Output of sudo docker info (after systemctl restart docker):

 Debug Mode: false

 Containers: 34
  Running: 19
  Paused: 0
  Stopped: 15
 Images: 589
 Server Version: 19.03.6
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 
 runc version: 
 init version: 
 Security Options:
   Profile: default
 Kernel Version: 4.15.0-140-generic
 Operating System: Ubuntu 18.04.5 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 47.16GiB
 Name: linuxsrv
 ID: <redacted>
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: <redacted>
 Registry: https://index.docker.io/v1/
 Experimental: false
 Insecure Registries:
 Registry Mirrors:
 Live Restore Enabled: false

WARNING: No swap limit support
  • Please show output for systemctl cat docker Commented Apr 7, 2021 at 9:56
  • @AlexanderTolkachev see edit Commented Apr 7, 2021 at 22:57

2 Answers 2


There are multiple address pools used by docker. The default-address-pools applies to all new user created bridge networks. It's possible you'll need to delete and recreate those networks after changing this setting.

There's also bip, set in the daemon.json file with a line like:

"bip": ""

The bip setting applies to the default bridge network named bridge and needs to be set to the CIDR for the gateway on that bridge network (so you can't define it to, the trailing .1 was important).

And if you are using swarm mode, overlay networks have their own address pools shared across nodes in the overlay network. That needs to be configured during docker swarm init with the --default-addr-pool flag.

Lastly if you are running docker via snap, the location of this file is /var/snap/docker/current/etc/docker/daemon.json and it doesn't appear that is preserved across updates, so you'll need to replace this file again after an update.

  • I'm not using swarm nor have installed it via snap, so I'm giving the bip option a go. Although the docs say that it's "not recommended for production use"... Commented Apr 7, 2021 at 23:56
  • @RodyOldenhuis that's correct, using the network is not recommended. But it's the default so docker always creates it even if you don't use it. Which means it will have an IP CIDR block assigned and routing table entry added to the host. Unfortunately you have to set each of the ranges for different parts of docker separately.
    – BMitch
    Commented Apr 7, 2021 at 23:59
  • Unfortunately, that appears to be ineffective...Does my edit above tell you anything? Commented Apr 8, 2021 at 1:17
  • @RodyOldenhuis do newly created networks stay in the correct range? Did you cleanup networks in the wrong range? Please include how you are creating networks, and the output of docker info in the question.
    – BMitch
    Commented Apr 8, 2021 at 1:57
  • 1
    Upgrading Docker over the weekend indeed resolved this problem. Many thanks for sticking with me 😊 Commented Apr 18, 2021 at 20:37

Although I thought I resolved the problem using BMitch's answer, I was wrong - the docker0 address was still in the wrong 172.17.*.* range after boot.

After a lot more digging, it turned out that, somehow, I had multiple versions of dockerd installed:

  1. the one you get if you install as per the docs
  2. ...the one installed via Snap 🤦‍♂️

Apparently, the one from Snap was the one started at boot, while the other one was the one started by running sudo systemctl restart docker.

Uninstalling & purging the one from Snap that escaped (...evaded?) my attention finally solved this pesky problem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .