Fixing WSL Not Working After Moving Ubuntu from C to D

Understanding the Path Registration Issue

When you move the physical files of a Linux distribution from one drive letter to another, the Windows Subsystem for Linux does not automatically detect this change. The system relies on specific registry entries to locate the root file system. If these paths remain pointed at the old C:\ location, the command line interface will fail to start the distribution, displaying errors such as "The requested operation could not be completed" or simply hanging indefinitely.

This behavior is distinct from standard application portability because WSL manages state through a registered instance name. While you can manually copy files, the metadata linking the instance name to its storage location must be explicitly updated. Without correcting these pointers, any attempt to launch the distribution will result in a failure to initialize the virtual hard disk or ext4 file system image.

Prerequisites and Safety Measures

Before modifying any registry settings, it is crucial to ensure that all instances of your Ubuntu distribution are completely stopped. Running processes may lock files or maintain active connections that prevent safe configuration changes. Open PowerShell as an administrator and execute the following command to halt all running distributions:

wsl --shutdown

Verify that no background processes are lingering by checking the Task Manager for any vmwp.exe (Virtual Machine Worker Process) tasks associated with WSL. Once confirmed, proceed with backing up your registry. Navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss and export the key containing your distribution's GUID. This backup allows you to restore original settings if the migration causes unexpected boot failures.

Updating Registry Keys via PowerShell

The most reliable method to fix the broken link is to update the registry directly using PowerShell. You need to identify the GUID of your Ubuntu instance and modify two specific values: InstallLocation and RootFSPath. First, retrieve the list of installed distributions to find the correct GUID:

wsl -l -v

Note the UUID listed next to your Ubuntu version. Then, open an elevated PowerShell session and run the following script, replacing YOUR-UUID-HERE with the actual identifier and D:\WSL\Ubuntu with your new target directory:

$guid = "YOUR-UUID-HERE"
$regPath = "HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss\$guid"
Set-ItemProperty -Path $regPath -Name "InstallLocation" -Value "D:\WSL\Ubuntu"
Set-ItemProperty -Path $regPath -Name "RootFSPath" -Value "D:\WSL\Ubuntu\rootfs"

This script updates both the installation root and the specific path to the read-write file system layer. It is vital that the RootFSPath points exactly to where the ext4.vhdx file resides within your new structure. After executing these commands, restart the WSL service by running wsl --shutdown again to clear any cached states.

Verifying the Migration Success

Once the registry is updated, test the connection by launching the distribution directly. Run the following command to start Ubuntu and verify that it boots without errors:

wsl -d Ubuntu

If successful, you should see the bash prompt appear immediately. Check that your previous configurations, aliases, and installed packages are intact by listing files in your home directory. If you encounter permission errors, ensure that the new directory on the D drive retains the same NTFS permissions as the original C drive location. You may need to take ownership of the folder if the migration involved moving directories across different user contexts.

For users who frequently switch between drives or external storage, understanding how WSL handles path resolution is essential. Similar challenges arise when attempting to transfer installations to USB drives, which require additional considerations for performance and stability. For more insights on portable WSL setups, explore our guide on transferring installations to external media.

Handling Common Post-Migration Errors

Even after updating the registry, some users report that the distribution fails to mount properly. This is often caused by residual cache files stored in the %LOCALAPPDATA%\Packages folder. Clearing these caches forces WSL to re-read the new registry paths upon next launch.

Another common issue involves network connectivity appearing lost after the move. Since the virtual network adapter is tied to the VM instance rather than the file system, this usually resolves itself after a full shutdown and restart. If issues persist, check that the D drive is formatted with NTFS, as exFAT or FAT32 volumes do not support the necessary file attributes for WSL operations.

If you experience difficulties opening web links from within your newly migrated Ubuntu environment, ensure that your default browser associations are still valid. Sometimes, moving the entire subsystem can reset internal environment variables related to URL handling. For troubleshooting these specific integration issues, refer to our article on default values for opening links in WSL.

Frequently Asked Questions

Can I use symbolic links instead of moving the files?

Yes, creating a symbolic link from the original C drive path to your new D drive location is a valid alternative. This method avoids registry edits but requires careful management to ensure the symlink is not broken by drive letter changes or maintenance tools.

Does moving WSL affect my Windows host performance?

No, the migration only changes where the virtual disk images are stored. Performance depends primarily on the speed of the underlying storage medium. Moving to a faster NVMe drive on the D partition may actually improve I/O throughput compared to a slower primary SSD.

What should I do if wsl.exe still cannot find the distribution?

Double-check that the RootFSPath registry value ends with \rootfs and not just the parent directory. Also, verify that the ext4.vhdx file exists in that exact path. A mismatched path is the most common cause of persistent "not found" errors.

Is it safe to delete the old files on the C drive immediately?

No, wait until you have verified that the new installation on the D drive is fully functional. Keep the original files for at least one week as a fallback. Once you confirm that all scripts, databases, and configurations work correctly, you can safely remove the old data to reclaim space.

How do I revert to the original C drive location if this fails?

You can restore the registry backup you created earlier before making changes. Alternatively, manually set the InstallLocation and RootFSPath back to their original C drive paths using the same PowerShell commands provided in this guide.