2.4 KiB
Local Docker Desktop socket recovery — 24 October 2026
The reported initializing Inference manager ... dockerInference ... file cannot be accessed
startup failure was reproduced locally. The listener path was a zero-byte Windows reparse-point
socket; removing/moving that leaf failed with Windows error 1920. After preserving its runtime
directory, startup advanced to the same problem with the Secrets Engine's engine.sock.
A subsequent failed startup had left a new inference socket, so both socket-only directories
needed to be preserved together after stopping the task-started backend process tree.
The successful attempt retained these directories as archives and created fresh originals:
%LOCALAPPDATA%\Docker\run.stale-20261023-rd21%LOCALAPPDATA%\docker-secrets-engine.stale-20261024-rd21%LOCALAPPDATA%\Docker\run.stale-20261024-rd21-4e4339f5%LOCALAPPDATA%\docker-secrets-engine.stale-20261024-rd21-805dc9e6
Each directory's contents were inspected first: only zero-byte socket reparse points, no ordinary
files or subdirectories. No Docker data directory, image, user container, volume, WSL disk or
production resource was removed or reset. Docker then started successfully: local context
desktop-linux, engine 29.7.2; health checks, pinned MariaDB containers, 32 integration cases and
the native browser recovery case passed. Docker's own updater downloaded an available installer;
this task did not install it or request a Docker upgrade.
Do not blindly repeat directory moves while Docker is running, archive broader Docker directories, or perform a factory reset. If this recurs, capture the exact startup error, stop only the affected local Desktop process tree, verify that each named path still contains only disposable sockets, and preserve it before replacement. Persistent data or unclear contents need separate review.
Before Docker recovered, an initial task-owned image extraction filled Docker Desktop's small
bootstrap filesystem. The failed extraction was removed from its verified task-specific temporary
directory and free space restored. The successful fallback used a private 2GB tmpfs and mount
namespace under WSL; it passed the same real MariaDB tests but was labelled separately from Docker
execution. That fallback server was gracefully shut down before retrying Desktop. No preexisting
database or user data was deleted. Raw logs and before/after metadata remain under the ignored
.artifacts/mariadb/ directory.