Docker Desktop Bind Mounts Vanish After Reboot

I recently ran into an odd issue using Docker Desktop for Windows that caused me several hours of head scratching.

I use a pretty common setup for local development on Windows:

I do most of my interaction with WSL2 and Docker via VSCode’s WSL terminal.

The issue I ran into is that my Postgres Docker container would not retain data in my configured bind mounts through system reboots.

I typically use docker-compose syntax, but this applies to containers run with docker run as well.

A sample of my docker-compose.yml file:

services:
  db:
    image: postgres:16
    container_name: my_db
    ports:
      - "5432:5432"
    volumes:
      - db/data:/var/lib/postgresql/data
      - db/backups:/var/lib/postgresql/backups
    restart: unless-stopped
    env_file:
      - .env

I tested this configuration on a pure Linux box and found that it works as expected.

I tried another container project I have that uses a MongoDB database.

That container exhibited the same odd behavior on my local workstation.

While trying different troubleshooting steps, I noticed that if I stopped the container and then restarted it, the original databases now existed and contained the expected data.

The issue turns out to be that Docker Desktop on Windows attempts to start the container before the WSL2 mount point is accessible.

For me, the solution was to change my development docker-compose.yml file to use Docker Volumes:

services:
  db:
    image: postgres:16
    container_name: my_db
    ports:
      - "5432:5432"
    volumes:
      - db_data:/var/lib/postgresql/data
      - db_backups:/var/lib/postgresql/backups
    restart: unless-stopped
    env_file:
      - .env

volumes:
  db_data:
  db_backups:

Or docker run:

docker volume create db_data
docker volume create db_backups

docker run -d \
  --name my_db \
  -p 5432:5432 \
  --env-file .env \
  -v db_data:/var/lib/postgresql/data \
  -v db_backups:/var/lib/postgresql/backups \
  postgres:16

A less desirable solution, at least in my case, was to set the container not to automatically restart and then start it manually after Docker Desktop was initialized.

about me

An information technology professional with twenty six years experience in systems administration, computer programming, requirements gathering, customer service, and technical support.