Docker Desktop Service FS Failed Or Backend Deadlock On Mac

When Docker Desktop reports `service fs failed: injecting event blocked for 60s`, hangs after disk pressure, or loses access to containers, treat it as two problems: recover the backend, then identify whether host disk, Docker.raw, file sharing, logs, cache, or volumes caused the failure.

Docker Desktop looks wedged after a file sharing or disk-space failure. Please do not reset Docker Desktop yet because that can remove local images, containers, and named volumes.

First capture read-only evidence:

df -h
du -sh "$HOME/Library/Containers/com.docker.docker/Data" 2>/dev/null
du -sh "$HOME/Library/Containers/com.docker.docker/Data/log" 2>/dev/null
ls -lh "$HOME/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw" 2>/dev/null
docker system df -v 2>/dev/null || true

If Docker answers, prune rebuildable build cache and unused images before touching volumes. If Docker does not answer, record that timeout as evidence and restart Docker Desktop before deciding whether a reset is necessary.

When The Error Is `service fs failed`

This failure often points at Docker Desktop's file sharing layer being overwhelmed or blocked, but it can still look like a storage incident when containers freeze, Docker cannot answer, or a reset risks losing volumes.

• Check whether large mounted folders include rapidly changing paths such as .git, .idea, node_modules, generated media, or build outputs.
• Record Docker Desktop file sharing mode and mounted host paths before changing settings.
• Capture disk pressure and Docker storage output before deleting data images or resetting Docker Desktop.

First, Capture Evidence

Before pruning anything, capture the difference between host disk pressure, Docker.raw growth, and Docker engine storage.

df -h
du -sh "$HOME/Library/Containers/com.docker.docker/Data" 2>/dev/null
du -sh "$HOME/Library/Containers/com.docker.docker/Data/log" 2>/dev/null
ls -lh "$HOME/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw" 2>/dev/null
docker system df -v

If the Docker CLI hangs, that is useful evidence too. It means the socket may exist while the backend is no longer reading requests.

Recovery Is Not The Same As Cleanup

Killing and restarting Docker Desktop may recover the engine after an ENOSPC hang. It does not explain which storage bucket filled the disk, and it does not prevent recurrence.

• Host pressure: large files outside Docker filled the APFS volume.
• Docker.raw pressure: Docker Desktop's virtual disk grew or stayed large.
• Docker cache pressure: images, build cache, containers, or volumes are consuming the Docker disk.
• Log pressure: backend or VM logs grow while the host has little free space.

If Containerd Panics After No Space Left

If Docker Desktop later reports a containerd panic, the earlier ENOSPC event may have interrupted writes to containerd metadata inside the VM. Before deleting all Docker data, capture the failing log path and check whether the VM disk can be expanded or Docker cache can be pruned safely.

• Look for io.containerd.metadata.v1.bolt/meta.db or repeated garbage collection errors in diagnostics.
• If Docker still starts enough to answer CLI calls, run docker system df -v before pruning.
• If Docker cannot start, treat a full reset as the last resort because it removes images, containers, volumes, and local databases.

Prevent The Next Deadlock

1. Keep a host free-space reserve before starting large Docker builds or imports.
2. Alert when free space drops below a fixed threshold, not just when Docker.raw is large.
3. Prune build cache and old images before touching volumes.
4. Review named volumes manually because they often hold databases or local service state.
5. Avoid deleting Docker.raw unless you intentionally want a Docker storage reset.