[BUG] Container created by Docker Compose 2.24.6 fails to reconnect to default NAT network on Windows restart

[michal-korniak-kornit]

Description

Description: I am experiencing an issue with Docker Compose 2.24.6 on Windows, using Docker version 25.0.3. The problem revolves around how these versions handle network connections to a pre-made NAT network after a system restart. This behaviour is inconsistent with that observed in Docker Compose 1.29.2 and when using Docker commands directly (docker run), which manage the scenario as expected.

To observe the behaviour, follow the steps described in the "Steps To Reproduce" section for both versions 2.24.6 and 1.29.2.

Steps To Reproduce

1. Use the following docker-compose.yml configuration:

services:
  mongo:
    image: mongo
    restart: unless-stopped
    networks:
      - nat
networks:
  nat:
    external: true

2. Start the container with Docker Compose using docker-compose up -d
3. Inspect the network mode of the container with docker inspect --format='{{.HostConfig.NetworkMode}}' mongo
4. Restart the Windows operating system.
5. Check if the container is up and running. If not, investigate the failure reason.

Findings:

• For Docker Compose 1.29.2:

1. The container starts correctly
2. The command docker inspect returns nat, indicating a connection by network name.
3. After a system restart, the container continues to operate correctly.

• For Docker Compose 2.24.6:

1. The container initially starts correctly.
2. However, docker inspect returns a network ID (e.g., 96d6b0255d82eb1f904a9a502f333957a5260bee69fd16b2ecf5f337a23f72de), showing a connection by network ID rather than by name.
3. After a system restart, the container fails to start with an error indicating that the network with the specified ID could not be found: Error: "could not find a network matching network mode 96d6b0255d82eb1f904a9a502f333957a5260bee69fd16b2ecf5f337a23f72de: network 96d6b0255d82eb1f904a9a502f333957a5260bee69fd16b2ecf5f337a23f72de not found."

Core Issue: The difference in the output of docker inspect between versions 1.29.2 and 2.24.6 is crucial. It reveals that version 1.29.2 connects to the network using its name, as anticipated, while version 2.24.6 uses the network ID for connection. This approach poses a problem after a system restart because the NAT network, though persistently present, is regenerated with a new ID. Consequently, this leads to a failure for containers expecting the network to retain the ID it had before the restart.

Temporary Workaround: I have temporarily addressed this issue by transitioning from Docker Compose to a script that utilizes docker run. This method consistently delivers the expected behaviour, similar to Docker Compose version 1.29.2, by connecting to the network using its name.

Compose Version

Docker Compose version v2.24.6

Docker Environment

Client:
 Version:    25.0.3
 Context:    default
 Debug Mode: false

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 1
 Server Version: 25.0.3
 Storage Driver: windowsfilter
  Windows:
 Logging Driver: json-file
 Plugins:
  Volume: local
  Network: ics internal l2bridge l2tunnel nat null overlay private transparent
  Log: awslogs etwlogs fluentd gcplogs gelf json-file local splunk syslog
 Swarm: inactive
 Default Isolation: process
 Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
 Operating System: Microsoft Windows Server Version 1809 (OS Build 17763.5458)
 OSType: windows
 Architecture: x86_64
 CPUs: 4
 Total Memory: 16GiB
 Name: WinServer2019-2
 ID: da86a901-e074-4baf-97df-bcacd34ca4e5
 Docker Root Dir: C:\ProgramData\docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

Anything else?

This issue renders the solutions specified in the following issue unusable: https://github.com/docker/for-win/issues/3076

[mllab-nl]

Same here, for me the workaround was adding network_mode: nat Docker run does the same.

services:
  mongo:
    image: mongo
    restart: unless-stopped
    network_mode: nat
    networks:
      - nat
networks:
  nat:
    external: true

Might be useful: While trying to make networking work stably on both (Server and Desktop) also faced this one for Docker Desktop: https://github.com/docker/for-win/issues/14014

[gilad-aperio]

The workaround of @mllab-nl worked for me, however this bug needs to be addressed. Bumping.

[Karatekid2407]

Same issue on my side, running on Unraid. Your solution is not working for me. :(

services:
  homeassistant:
    container_name: homeassistant
    image: lscr.io/linuxserver/homeassistant
    restart: always
    privileged: true
    environment:
      - TZ=Europe/Berlin
      - TCP_PORT_8123=8123
      - PUID=99
      - PGID=100
      - UMASK=022
    volumes:
      - /mnt/user/Docker/config/homeassistant:/config
    network_mode: br0
    networks:
      br0:
        ipv4_address: 192.10.10.110

networks:
  br0:
    external: true

get the following error on portainer

Failed to deploy a stack: service homeassistant declares mutually exclusive network_mode and networks: invalid compose project

[gilad-aperio]

Try to remove the other network attributes @Karatekid2407, as those are incompatible with network_mode. See here.

[Karatekid2407]

I understand but my current implementation is the same as the one from @mllab-nl which is working? Or do I miss something?

[gilad-aperio]

Maybe it could work for a past version of compose? I removed the networks part from the service block and it worked for me on version 3.9.

[Karatekid2407]

Ok but how can I then specify a fixed IP? I did not find any solution. The only idea I have at the moment is to

1. Use --force-recreate (don't know if I found the right option in Portainer)
2. define a custom network in my docker compose file