Repository navigation
WSL update: restored container starts before Ubuntu bind mount is ready and sees empty data (Desktop 4.94.0) #762
Description
Description
After a WSL update, Docker Desktop automatically recovered its WSL engine and restarted an existing container before Ubuntu integration had finished restoring its bind mount. The container then saw an empty/default application data directory even though the original files remained intact in Ubuntu.
docker inspect continued to report the expected bind source. Creating a fresh container with the same image and source immediately restored access to the original data, without restoring a backup.
Possibly related to #601. This report adds a WSL-update trigger and a timestamped startup/mount timeline.
Environment
- Docker Desktop: 4.94.0 (build 241994), verified from the running Windows executable's ProductVersion
- Docker Engine: 29.8.2
- Ubuntu 26.04.1 on WSL2, Ubuntu WSL Integration enabled
- WSL 3.0.3.0 installed during the incident
- Application image:
ghcr.io/hkuds/deeptutor:1.6.14 - Restart policy:
unless-stopped - Bind mount:
/home/<user>/high-school-math/data:/app/data - Published port:
3782:3782
Trigger and evidence
The incident occurred on October 13, 2026. Windows itself had not rebooted: LastBootUpTime was October 7, 2026, 18:11 UTC+8.
Windows Installer events show installation of wsl.3.0.3.0.x64.msi from C:\Windows\SoftwareDistribution\Download\…, beginning at 08:23:30 and completing successfully at 08:24:08 (UTC+8).
Docker logs show the Ubuntu proxy exiting, the WSL engine stopping, and automatic recovery.
All following times are UTC+8:
| Time | Evidence |
|---|---|
| 08:23:47 | Ubuntu integration proxy exited with status 1 |
| 08:23:57 | Docker WSL engine changed from running to stopping |
| 08:24:25 | Docker attempted recovery and started its WSL engine |
| 08:24:32.012 | Affected container's State.StartedAt |
| 08:24:35.058 | Ubuntu proxy logged mounting the application data directory into the internal bind-mount path |
| 08:24:36.103 | Docker logged "Ubuntu distro is ready" |
Sanitized excerpts:
[2026-10-13T00:24:25.144394300Z][com.docker.backend.exe.engines][W]
wsl-bootstrap failed, restarting (attempt 1 of 3)
[2026-10-13T00:24:35.058880300Z][com.docker.backend.exe.wsldistroproxy]
[2026-10-13T00:24:35.058008921Z][docker-desktop-user-distro.apiproxy]
mounting /home/<user>/high-school-math/data to
/mnt/wsl/docker-desktop-bind-mounts/Ubuntu/<mount-id>
[2026-10-13T00:24:36.103755900Z][com.docker.backend.exe.wslintegrationagent]
Ubuntu distro is ready
Affected container inspection:
Created: 2026-10-10T07:13:13.582152619Z
StartedAt: 2026-10-13T00:24:32.012120161Z
RestartCount: 0
OOMKilled: false
RestartPolicy: unless-stopped
Mount source: /home/<user>/high-school-math/data
Mount target: /app/data
Mount type: bind
Observed behavior
Comparing Ubuntu's source directory with /app/data in the affected container:
| Check | Ubuntu source | Affected container |
|---|---|---|
| PDFs | 36 | 0 |
| Knowledge bases | 5 | 0 |
| Model configuration size | 22,690 bytes | 889 bytes, default configuration |
The app appeared to have reset: books, learning records, and model settings were missing from its UI. The original source directory still held the reading library and learning database.
The affected container was healthy because the app could initialize a fresh data tree. Application health did not detect that the intended persistent data was unavailable.
Recovery verification
- A temporary container using a fresh read-only bind of the same Ubuntu source could see the original files.
- Stopped and retained the affected container, and saved a copy of its visible data separately.
- Recreated the app container using the same 1.6.14 image, port and source path.
- The new container immediately saw the original data.
- Read-only API checks returned 11 reading materials, 5 ready knowledge bases and the existing learning topic. The learning database retained 65 interactions and 422 events.
- Tracked settings and learning-data hashes were unchanged. No backup restoration or application upgrade was needed.
Expected behavior
Containers restored after a WSL engine restart should bind to the actual Ubuntu source directory, or fail/defer startup until that bind is ready, instead of starting successfully against an empty/default directory.
Reproduction status / suspected mechanism
This was observed once following the WSL update. I have not intentionally repeated the update/restart because the app contains persistent data.
The ordering suggests a race between restoring containers and restoring Ubuntu bind mounts. A stale or placeholder mount view is a hypothesis, not a confirmed implementation-level diagnosis.
Diagnostics
No full Docker diagnostic bundle has been uploaded yet. This report is based on read-only inspection of existing Docker Desktop logs, Windows Installer events, container metadata, and application data.
Activity