Choosing WSL's Default Distribution Install Path Without Moving Existing Data

WSL has more than one way to choose where a Linux distribution is stored. The current .wslconfig reference lists distributionInstallPath under [general] as the default Windows directory for newly installed distributions. The wsl --install command also accepts --location to specify a folder for that installation. Imported distributions use an explicit install location as part of the import command. These controls solve different planning problems: one establishes a default for future Store-style installs, another overrides a particular install, and neither should be confused with moving an already registered distribution.

Choosing the location before installing can prevent a small system drive from accumulating virtual disk files. But a path change does not resize a VHDX, relocate existing data, or change the location of every WSL artifact such as the WSL package itself or swap storage. Confirm the destination with the command used to create each distro rather than assuming the setting retroactively changes storage.

Understand which operation owns the location

The [general] setting is in %UserProfile%\.wslconfig, outside Linux. It is global to WSL on that Windows user profile. Microsoft’s current reference gives %LocalAppData%\wsl as its default and describes distributionInstallPath as the absolute Windows path for the default directory of newly installed distributions. Existing registered distros should be treated separately. The setting’s wording does not say that changing it moves an existing VHDX.

For a single wsl --install operation, --location explicitly selects the folder. This is useful when a machine has multiple storage volumes or when an installation should not use the profile-wide default. For a tar-based wsl --import, the destination is already an explicit positional argument. Do not substitute one operation’s flags for another: inspect wsl.exe --help on the target runtime and use the syntax documented for that command.

The exact data layout is managed by WSL and may differ by install source and runtime generation. Treat a directory path as a storage location, not a contract about private file names or internal directory structure. Avoid scripts that rename, move, or rewrite WSL’s registered files behind the command-line interface. Use the supported WSL lifecycle commands for operations such as export, import, and unregister.

Inventory before planning capacity

Start with the actual Windows and WSL state:

wsl.exe --version
wsl.exe --list --verbose
Get-Content "$env:USERPROFILE\.wslconfig" -ErrorAction SilentlyContinue
Get-Volume | Select-Object DriveLetter, FileSystemLabel, FileSystem, Size, SizeRemaining

This captures the runtime, registered distributions, current global configuration, and volume capacity. It does not reveal a supported, stable way to infer every distro’s VHDX path from registry internals. For a planned new install, record the exact command and destination as part of the deployment record. If you need to find a current distribution’s storage, use supported Windows/WSL management surfaces rather than editing internal registry values.

When choosing a folder, check available space, filesystem support, backup policy, and whether the volume is local or removable. A WSL 2 distribution stores a Linux filesystem in a virtual disk, so host-side free space and the guest’s reported free space are related but not identical. A dynamically growing VHD can consume host storage over time, and a configured maximum size is not the same as reserved free space. Keep the separate VHD sizing and sparse-disk policies in view; changing the installation directory does not change them.

Set a default for future installs

Preserve all existing .wslconfig values and add or update a single [general] section. For example:

[general]
distributionInstallPath=D:\\WSL\\Distros

The configured value is a Windows absolute path. Microsoft documents escaped backslashes for path entries in .wslconfig. Use a directory on a volume that is mounted and available before WSL installation; do not select a temporary directory or a network path unless the current WSL documentation and your organization’s support model explicitly permit that scenario. Avoid placing WSL’s active distro data inside a directory that an automatic cleanup or sync client may rename or remove.

Before relying on the global default, test one noncritical new installation with a clear name and check that it starts correctly. The configuration applies to subsequent new installs, not every existing registration. A per-install override can make a deliberate exception:

wsl.exe --install --distribution Ubuntu --location D:\WSL\Ubuntu-Test --no-launch
wsl.exe --list --verbose

The exact availability of --location may depend on Windows and WSL command versions; the current Microsoft basic commands reference lists it. If the command rejects the flag, stop and inspect wsl.exe --help rather than falling back to undocumented registry changes. The example’s --no-launch keeps first-run initialization separate so the install command’s effect can be checked before a user setup prompt appears, where supported.

For a deliberate import, its target directory is explicit:

wsl.exe --import LabDistro D:\WSL\LabDistro .\rootfs.tar --version 2
wsl.exe --list --verbose

An import path does not depend on distributionInstallPath; the import command names its install location. Imported distros may need default-user configuration after registration. Keep a verified backup of source data before an import or migration, and do not unregister the source until the target has passed validation.

Verify placement and behavior without guessing private internals

Use the supported command’s successful completion, registered distro name, WSL version, and a test launch as your primary evidence. Confirm the requested Windows volume exists and has sufficient free space. If WSL Settings or another official management UI exposes a location, compare it with the recorded target. Do not search the registry for an undocumented file path and then build production automation around it.

Validation should include more than wsl --list. Launch the distro, verify /etc/os-release, confirm the expected default user, create a small test file in the Linux root filesystem, stop the distro, and start it again. From Windows, check that the chosen volume remains available and that no volume encryption, access control, or corporate storage policy blocks subsequent starts. A distro can register successfully and still fail later if its storage volume is removed or unavailable.

For wsl --install --location, check the result before repeating an install command. Re-running commands with the same distro name can fail or target an unintended registration. For imported distributions, use a unique name and a destination that does not already contain unrelated data. Do not run wsl --unregister as a cleanup shortcut until you have verified the name and backed up anything valuable; unregistering removes that distro’s registration and data.

Existing distributions need a separate migration plan

Changing distributionInstallPath is not an existing-distro move operation. If the objective is to relocate an installed distribution, consult current official WSL management documentation for a supported move workflow or plan a verified export/import migration. Before any move, stop services cleanly, export or otherwise back up data, record distro version and default user, verify filesystem and storage requirements, import to a new path, validate applications, and retain the source until the new copy is accepted.

Do not copy an active VHDX while WSL is writing to it and assume the copy is consistent. A snapshot or export can also omit operational state outside the Linux filesystem, such as Windows-side launch configuration or secrets held in the Windows user profile. The installation path setting alone does not capture those dependencies. For reliable migration, document both WSL registration metadata and distro contents, then test the restore on the same supported WSL generation.

Capacity and lifecycle checklist

Before rolling out a default path, make the owner and purpose of each location explicit: a profile-wide future-install default, a per-install override, an explicit import destination, and any separate VHD or swap location. Record the exact WSL package version, Windows build, command line, target volume, and resulting distro name. Add monitoring for host free space on the selected volume and a process for backing up distributions before storage maintenance.

Revalidate after a WSL update, Windows reinstall, profile migration, or change in volume letters. If a drive letter can change, a hard-coded path can stop matching the intended volume; use stable local storage planning rather than assuming letters never move. Do not use a path setting to imply portability: an installed distro remains registered to the Windows WSL installation and user context that manage it.

The safe operational rule is simple: use distributionInstallPath to define a default for new installations, --location for an intentional install-specific destination, and the import command’s explicit path for imports. For existing registered distributions, use a separately documented migration procedure and validate the result before removing the original.

Related:

Sources: