Docker Desktop 4.93 on Apple Silicon: disk-image relocation canceled after ~301 seconds; request supported 4.95.0 remedy #753

Bug report

Summary

Docker Desktop's supported disk-image relocation failed twice on an Apple Silicon Mac using Docker Desktop 4.93.0and an external APFS Encrypted SSD. Both attempts failed after approximately 301–303 seconds. A separate verified cold-copy adoption attempt was rejected by the destination-folder selector.

We now run Docker Desktop 4.95.0, but have not retried relocation or adoption on 4.95.0. Our current internal Docker.raw contains newer database writes and must remain authoritative. We request a documented, non-destructive workaround.

Related, potentially different failure: https://github.com/docker/desktop-feedback/issues/484 (reported cp SIGKILL; our failure was request timeout/context cancellation).

Reproduction: relocation timeout (4.93.0)

1. Open Settings > Resources > Advanced > Disk image location.
2. Select a location on the external APFS SSD and apply.
3. The local GUI request POST /app/settings/gui runs for approximately 301 seconds and fails:

Headers Timeout Error
failed to move VM disk: context canceled.
New setting not applied

The original internal image stays active. A later attempt over a negotiated 10 Gb/s USB connection, with approximately 280 MB/s observed transfer, failed after about 303 seconds. We have not proven the root cause.

Reproduction: existing-image adoption (4.93.0)

A historical cold copy was hash-verified against its source at creation time. Sanitized destination:

/Volumes/ExternalSSD/DockerDesktop/Active/DockerDesktop/Docker.raw

Selecting /Volumes/ExternalSSD/DockerDesktop/Active reported:

Invalid path: [selected parent]/DockerDesktop already exists.
Please remove it and retry.

The documented use existing/replace image choice did not appear. This older copy is not current and must not replace subsequent database writes. Adoption on 4.95.0 has not been tested.

Read-only storage observations (17 Oct 2026)

The two historical internal files share clone extents; their allocations are not additive. APFS private size is diagnostic not proof of reclaimable physical host space. Prior individual guest image/cache retirement did not demonstrate a corresponding host-space increase. Protected databases, volumes and recovery copies must be preserved.

Questions for Docker Engineering

1. What is the officially supported 4.95.0 Apple Silicon relocation method for a current large sparse disk on an encrypted APFS SSD? Does it require capacity approaching the full logical disk size or only allocated bytes?
2. Is the ~301-second request timeout a known defect? Which version or supported procedure corrects it without undocumented settings edits?
3. What exact existing-image directory layout and selection should trigger the use-existing/replace option? Is consistent incremental synchronization supported, or must a new cold copy be made?
4. Is docker/desktop-reclaim-space supported on the current arm64 Docker Desktop VM? Our registry-only inspection observed an amd64 helper; it has not been run. Is automatic trim/discard preferred?
5. How do APFS clones/snapshots affect Mac host free-space recovery after a successful move or trim? How can actual freed host blocks be verified?
6. What shutdown, downtime, extra disk-space and rollback requirements should we follow? Our internal free-space floor is 32 GiB and the external SSD reserve is 20%.
7. Is issue Docker Desktop 4.79 fails to migrate Disk image location to APFS external SSD (cp terminated with SIGKILL), but manual migration succeeds #484 related, and is a corresponding fix present in 4.95.0 or a later version?

No Docker reset, privileged helper, manual disk rename, undocumented settings change, new relocation attempt, or deletion is authorized. No private logs, credentials, database contents, account identifiers, private paths, resource names or diagnostics are attached. Please provide a supported version-specific procedure and required safeguards.

Platform

macOS / Apple Silicon arm64

Version information

macOS 27.0.1 (build 26A434)
Docker Desktop 4.95.0 (build 242831)
Docker Client 29.8.2, API 1.56, darwin/arm64
Docker Engine 29.8.2, API 1.56, linux/arm64
containerd v2.3.6; runc 1.5.1; docker-init 0.19.0

Diagnostics ID

Not provided (no diagnostic bundle attached).