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:

• Docker Desktop
• WSL2
• Visual Studio Code with the WSL Remote extension

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.

After manually applying an update to one of the ColdFusion servers I manage I started getting this error when opening the ColdFusion Administrator console:

The administrator module is not installed.
You can install module through CLI package manager(CF_ROOT/bin/cfpm.bat) by running the command : install administrator.

Executing the suggested command showed what appeared to be a successful install, but still received the same error.

I reviewed the ColdFusion update log {cfusion}\hf-updates\hf-XXXX-XXXXX-XXXXXX and found several module installs failed with this error:

An error has occurred while installing the package XXXXX. Exception : URI does not specify a valid host name: {Local Path To File}.jar

An old manual upgrade path was left in the packagesurl value within {cfusion}\lib\neo_updates.xml.

I was able to restore my pre-update snapshot backup, change neo_updates.xml back to the original value of https://www.adobe.com/go/coldfusion-packages and proceed with the manual update normally.

If the packagesurl value contains invalid/unescaped characters, you might also see this error in the update log:

Exception : Illegal character in opaque part at index X

I found that after changing the password for a MongoDB NoSQL DSN using ColdFusion Administrator you need to restart the ColdFusion Application service in Windows. Even changing to the correct password will cause a MongoDB authentication error:

Exception authenticating MongoCredential{mechanism=SCRAM-SHA-256, userName='{Your Username}', source='{Your Auth Source}', password=, mechanismProperties=} null

Command failed with error 18 (AuthenticationFailed): 'Authentication failed.' on server XXXXXXXXXXXXX:27017. The full response is {"ok": 0.0, "errmsg": "Authentication failed.", "code": 18, "codeName": "AuthenticationFailed"}

This error may be logged in the MongoDB server log:

{"t":{"$date":"2021-11-08T14:39:07.067-06:00"},"s":"I",  "c":"ACCESS",   "id":20249,   "ctx":"conn122","msg":"Authentication failed","attr":{"mechanism":"SCRAM-SHA-256","speculative":false,"principalName":"{Your Username}","authenticationDatabase":"{Your Auth Source}","remote":"XXX.XXX.XXX.XXXX:51204","extraInfo":{},"error":"AuthenticationFailed: SCRAM authentication failed, storedKey mismatch"}}

After the most recent Windows 10 update (1703); my very solid and stable workstation started getting blue screens.

Being a windows user for more than twenty years I’ve come to expect the occasional BSOD. Things fail. It just happens.

So while the first BSOD was troubling; I was not immediately alarmed.

After the third BSOD I knew something was wrong.

Running WhoCrashed revealed the root cause to be:

netwtw04.sys

A bit of searching revealed that to be WiFi related.

I fixed my problem by downloading the latest reference drivers from my WiFi networking card manufacturer.

Ran across an interesting problem. While setting up a new Windows 2008 R2 erver and website on IIS; I noticed that the site was generating 500 errors when serving static files (images, css, html, etc.)

I turned on Failed Request Tracing and noticed that I was getting this logged

This configuration section cannot be used at this path. 
This happens when the section is locked at a parent level. 
Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".

Based simply on previous experience I went to the IIS Feature Delegation and reviewed the delegation for the various IIS modules.

I found that by setting Handler Mappings to Read/Write the error was resolved.

I’m still not sure why this causes a problem since I’m not defining any custom handlers at the site level.

Perhaps this setting must be read/write even when custom handlers are set at the server level?

I upgraded from Windows 7 Enterprise to Windows 8 Enterprise. My upgrade was very smooth. Probably the easiest Windows upgrade I’ve done. The new OS seems as solid as Windows 7. I thought the new Modern UI (aka Metro) would present a problem in my day to day use of the OS and applications. Surprisingly this is not true. While I’m not terribly impressed with the UI it’s fairly easy to ignore. It essentially replaces the Start Menu with a full screen UI. The Desktop view is still available and works as it has in previous versions of Windows.

In fact, the only real complaint I have about Windows 8 is that it’s going to be a tough sell to the casual user. The replacement of the Start Menu could be just enough to scare them and it doesn’t appear to enhance anything about the Windows experience. In my short time with Windows 8 I’ve already spent 99% of my time outside of the Modern UI and it’s Apps.

Windows 8 is a good OS, but probably not worth the upgrade for the casual computer user.