How to Move Docker Desktop Data to Another Drive on Windows 11

Your primary development drive is suffocating under layers of dangling build caches, heavy-weight Linux container images, and unpruned volumes, and Windows 11 has run out of headroom. As a developer running Docker Desktop via WSL 2, your default ext4.vhdx virtual disk has likely ballooned to 60GB, 100GB, or more, sitting squarely on your cramped primary NVMe drive while your secondary data drive sits mostly empty. Because Docker Desktop for Windows buries this virtual hard disk inside deeply nested hidden AppData directories, freeing up space requires more than just running docker system prune. You need to surgically relocate the underlying WSL 2 data distro to a high-capacity drive without breaking your active containers, corrupting your volumes, or losing your local configuration state.

TL;DR: The 5-Minute Migration

If you just want the fast-track sequence of commands without reading the underlying mechanics, execute these steps in your Windows Terminal (running as your standard user, not elevated).

# 1. Stop Docker Desktop completely
Get-Process "Docker Desktop" -ErrorAction SilentlyContinue | Stop-Process -Force
wsl --shutdown

# 2. Export the live data distro to a temporary tarball
wsl --export docker-desktop-data "D:\docker-backup\docker-desktop-data.tar"

# 3. Unregister the original data instance
wsl --unregister docker-desktop-data

# 4. Import the tarball back into your target directory
wsl --import docker-desktop-data "D:\Docker\wsl\data" "D:\docker-backup\docker-desktop-data.tar" --version 2

# 5. Clean up the temporary archive and restart Docker
Remove-Item "D:\docker-backup\docker-desktop-data.tar"
& "C:\Program Files\Docker\Docker\Docker Desktop.exe"

If everything goes to plan, Docker Desktop boots up within a minute, your containers are intact, and your primary drive has recovered dozens of gigabytes. If you hit a permission error, a missing path, or a WSL state lock, read on for the step-by-step breakdown.

Step 1: Verify Your Environment and Shut Down

Before moving any files, you need to understand how Docker Desktop stores its data on Windows 11. Unlike older Hyper-V backends, modern Docker Desktop relies entirely on the Windows Subsystem for Linux (WSL 2). It splits its operations across two distinct WSL utility distributions:

docker-desktop: Contains the application binaries and core daemon logic.
docker-desktop-data: Contains the actual container root filesystems, images, build caches, and named volumes stored inside a monolithic virtual disk file (ext4.vhdx).

By default, WSL stores these distributions under your user profile: %LOCALAPPDATA%\Docker\wsl.

Open PowerShell and check your current WSL distribution states to ensure everything is running cleanly:

wsl -l -v

Expected output:

  NAME                   STATE           VERSION
* docker-desktop         Running         2
  docker-desktop-data    Running         2

To prevent file corruption during the migration, you must completely terminate the WSL engine and ensure Docker Desktop is not holding locks on the virtual disk. Quit Docker Desktop from the system tray, then run these termination commands:

# Force-kill any lingering Docker GUI processes
Stop-Process -Name "Docker Desktop" -ErrorAction SilentlyContinue

# Shut down the WSL subsystem entirely
wsl --shutdown

Verify that the shutdown was successful by running wsl -l -v again. All states should read Stopped. If a distribution refuses to stop, close all open terminal windows running WSL instances and try wsl --shutdown once more.

Step 2: Export the Data Distro

WSL 2 provides a built-in export mechanism that serializes an entire Linux distribution—including its file permissions, block allocations, and data layers—into a single tar archive. This is far safer than manually copying and moving the ext4.vhdx file, which often results in hard-coded path mismatches or permission stripping by the Windows NTFS file system.

First, create a temporary directory on your target drive (for example, D:\docker-temp) to hold the intermediate archive. Ensure your target drive has at least twice the free space of your current ext4.vhdx size, as the export process requires breathing room to write the tarball.

Run the export command:

wsl --export docker-desktop-data "D:\docker-temp\docker-desktop-data.tar"

Depending on the size of your ext4.vhdx file, this command can take anywhere from 30 seconds to 10 minutes. It will not output any text to the console while running; wait patiently until the PowerShell prompt returns.

Once the command completes, verify that the .tar file exists on your target drive and matches the approximate size of your old data storage:

Get-Item "D:\docker-temp\docker-desktop-data.tar" | Select-Object Name, Length

Step 3: Unregister and Relocate

Now that your data is safely serialized inside the tarball, you must unregister the existing docker-desktop-data distribution from WSL. This action deletes the original ext4.vhdx file from your AppData directory, instantly reclaiming that space on your primary drive.

Execute the unregister command:

wsl --unregister docker-desktop-data

Expected output:

Unregistering...
The operation completed successfully.

Next, create the destination folder where your new, relocated WSL data directory will live. For this example, we will use D:\Docker\wsl\data.

New-Item -ItemType Directory -Path "D:\Docker\wsl\data" -Force

Now, import the tarball back into WSL, pointing it to your new directory on the target drive. This command generates a brand new ext4.vhdx file inside D:\Docker\wsl\data, configured to use WSL version 2.

wsl --import docker-desktop-data "D:\Docker\wsl\data" "D:\docker-temp\docker-desktop-data.tar" --version 2

Like the export step, this import process runs silently and can take a few minutes. Once the prompt returns, check your target directory: you should see a newly generated ext4.vhdx file whose size mirrors your previous environment.

Finally, clean up the temporary tarball to reclaim that intermediate disk space:

Remove-Item "D:\docker-temp\docker-desktop-data.tar" -Force

Step 4: Boot and Verify

Launch Docker Desktop from your Windows 11 Start Menu or shortcut.

Watch the system tray icon: it should transition from the starting animation to the steady green state within 30 to 60 seconds. Open a new terminal window and verify that your containers and images are fully intact:

docker ps -a
docker images

If your running containers appear and your persistent volumes return their data, the migration was successful. You can now open File Explorer, navigate to %LOCALAPPDATA%\Docker\wsl, and confirm that the data folder is either gone or empty, proving that Docker is now reading and writing exclusively to your secondary drive.

Troubleshooting Common Failure Points

Even with careful execution, Windows file locks and WSL version mismatches can cause hiccups. If Docker fails to start or your containers are missing after the migration, consult these common failure points.

Error: "The system cannot find the file specified" during import

This usually happens if the target directory path contains typos or if you forgot to create the destination folder using New-Item. WSL cannot automatically create nested parent directories during an import in certain Windows permission contexts. Always manually create the destination folder path before running wsl --import.

Docker gets stuck on "Starting the engine" indefinitely

If Docker hangs on startup, the WSL background services have likely failed to mount the newly imported distribution properly.

Open PowerShell and run wsl --shutdown.
Check your WSL status with wsl -l -v. If docker-desktop-data shows a status other than stopped, force-kill the associated LxssManager service:
```
Get-Service LxssManager | Restart-Service -Force
```
Restart Docker Desktop.

WSL version fallback to version 1

If you omit the --version 2 flag during the wsl --import command, WSL may default to version 1. Docker Desktop requires WSL 2 to function. If you suspect this occurred:

Run wsl --l -v and check the version column for docker-desktop-data.
If it reads 1, unregister the distribution again (wsl --unregister docker-desktop-data), re-export/re-import ensuring you append --version 2 to the import command.

Preventing Future Bloat

Moving your Docker data to a larger drive solves the immediate storage crisis, but without basic hygiene, your new ext4.vhdx file will eventually bloat your secondary drive as well.

WSL 2 virtual hard disks have a frustrating quirk: they automatically grow in file size when you create data, but they never automatically shrink when you delete data. If your ext4.vhdx swells to 120GB, deleting all your containers will only free up space inside the virtual disk; the physical .vhdx file on your disk will remain 120GB.

To actively manage disk usage and prevent runaway growth, run these maintenance commands monthly:

# Prune all stopped containers, unused networks, dangling images, and build caches
docker system prune -a --volumes --force

If your .vhdx file has already bloated past your actual data requirements and you need to physically shrink it, you must reclaim the unallocated space from the WSL side:

Shut down Docker and WSL:
```
wsl --shutdown
```
Open Diskpart or use PowerShell to optimize the virtual disk. The cleanest method is using the Windows Diskpart utility:
```
diskpart
```

Once inside the DISKPART> prompt, execute:

SELECT VDISK FILE="D:\Docker\wsl\data\ext4.vhdx"
COMPACT VDISK
EXIT

Compacting the virtual disk reclaims the unused internal blocks, shrinking the physical file size on your secondary drive and keeping your development environment lean.