Problem: Docker Desktop fails to start: The file cannot be accessed by the system / orphan AF_UNIX socket —— Trove problem library

What you will run into

Docker Desktop's engine refuses to start and the GUI shows an error dialog. com.docker.backend.exe.log contains:

starting services: initializing Ingest server: listening on unix://C:/Users/<user>/AppData/Local/Docker/run/sailor-ingest.sock: remove ...: The file cannot be accessed by the system

The annoying part: fixing one socket reveals the next - sailor-ingest.sock -> docker-secrets-engine/engine.sock -> dockerInference, a different socket fails on every restart.

Typical trigger: Docker Desktop exited abnormally (force-kill, crash, power loss), or a hung docker desktop start CLI interrupted mid-run.

Why this happens

After an unclean exit, %LOCALAPPDATA%\Docker\run\ and %LOCALAPPDATA%\docker-secrets-engine\ keep orphan AF_UNIX socket files that carry the ReparsePoint attribute, so Windows refuses to delete them (error 1920: The file cannot be accessed by the system).

The engine must remove those stale sockets at startup; failing that, the whole start fails.

Docker Desktop's Windows-side engine communicates with the WSL side through AF_UNIX socket files; on a clean exit the engine removes them, but after an unclean exit (power loss / forced kill) the cleanup never runs and the socket files are left behind.

Windows protects files with the ReparsePoint attribute at the filesystem level (deletion fails with error 1920) — this is OS behavior, not a Docker bug, which is why normal delete APIs, Remove-Item, and even WSL rm are all rejected.

Deterministic takeaway: the failure is not about permissions, it is the reparse-point attribute; the official "rename the parent directory" workaround bypasses the deletion restriction rather than the file itself;

first make sure EnableDockerAI in settings-store.json is false, otherwise the next start rebuilds dockerInference and kills startup again.

Step by step

1. Confirm this is the bug from the log — Required

Search %LOCALAPPDATA%\Docker\log\host\com.docker.backend.exe.log for The file cannot be accessed by the system / GET /error. Hit -> skip all delete attempts, go straight to the rename.

2. Stop Docker and rename the directories — Required

After all Docker processes are gone, rename both directories (rename works, delete never does). Docker recreates clean run / docker-secrets-engine dirs on the next start.

3. Turn off EnableDockerAI — Required

%APPDATA%\Docker\settings-store.json: "EnableDockerAI": false. Otherwise the Inference manager kills startup again.

4. Start and verify — Required

Start-Process 'C:\Program Files\Docker\Docker\Docker Desktop.exe'
docker version --format '{{.Server.Version}}'
docker ps

5. Clean up — Required

After the engine is healthy, remove the old dirs: wsl -d Ubuntu bash -lc "rm -rf /mnt/c/Users/<user>/AppData/Local/Docker/run.old-* /mnt/c/Users/<user>/AppData/Local/docker-secrets-engine.old-*" (once renamed, even the stubborn reparse files can be wiped).

How to confirm it works

docker version returns the server version, docker ps lists containers; a restart no longer shows The file cannot be accessed by the system.

Other environments

Symptom

Docker Desktop engine fails to start; log shows listening on unix://...sailor-ingest.sock: remove ...: The file cannot be accessed by the system; GUI shows unexpected error; fixing one socket reveals the next.

Cause

Orphan AF_UNIX sockets from an unclean exit carry the ReparsePoint attribute, so Windows refuses deletion (error 1920); the engine cannot remove the stale sockets at startup -> whole start fails.

Solution

1. Confirm The file cannot be accessed by the system in the log;
2. Stop all Docker processes;
3. Rename (do not delete) %LOCALAPPDATA%\Docker\run and %LOCALAPPDATA%\docker-secrets-engine;
4. Set EnableDockerAI=false in settings-store.json;
5. Start Docker Desktop.exe directly and poll docker version until ready;
6. Clean up the old dirs afterwards.

Related canonicals

Read in order: precondition -> same root / same domain / related:

• Related (similar errors, different cause):
• Cannot connect to the Docker daemon (contains: the orphan socket is the Desktop-specific root cause of daemon connect failures)