I just ran into this. Running any container with docker run -it <image> bash, I was able to do anything network related that I needed, but attaching to a container started through docker-compose with docker exec -it <conatiner> bash could run nothing. Even apt-get would fail with a "temporary failure in name resolution error."
I found that adding network_mode: "bridge" to each service would enable external networking in each container, at the expense of attaching everything to the default docker network. I wanted to keep the stack isolated though, so set about an alternative solution.
I ran docker inspect network bridge to view the default network, and the same with my stack network. The only significant differences I found were a difference in subnet/gateway (which I believe is to be expected, however the IPs listed differed significantly, 192.* vs 172.*), and that the default network had several options that were not present in the stack network:
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
I was able to isolate it to "com.docker.network.bridge.default_bridge": "true", however this broke networking for containers outside the stack, to the point where I eventually had to completely remove and reinstall docker. I'm assuming the docker daemon gets confused with two networks marked as default and is unable to resolve it, even after removing the stack network.
One thing I noticed after doing that though was that the subnet and getway were just off by one from the default adapter. I verified that removing the above option reverted the subnet and gateway to what I saw originally, which it did. I then used this network config in my compose file:
networks:
default:
driver: "bridge"
ipam:
driver: default
config:
- subnet: X.X.0.0/16
Where the first value of the subnet was the same as the default bridge adapater, and the second value was plus one. And that at least got everything working fine, sans the default adapter still being broken.
Interestingly enough, when I went to reinstall docker to try and repair the default network, I basically ran the following after looking at the docker compose network documentation for external networking.
sudo snap remove docker
sudo sysctl net.ipv4.conf.all.forwarding=1
sudo iptables -P FORWARD ACCEPT
sudo snap install docker
And a subsequent docker-compose up -d with the network settings removed resulted in the same subnet IP that I had defined earlier without having the config present for it. I believe the underlying issue is simply that something was preventing the docker daemon from properly finding an available, valid subnet, and once that is resolved everything should again work out of the box.
