Same thing happened to me. Tried with junction first, then symlink

This would be really nice, as I generally keep my system disk not so big

Same issue. Hope it could move to disk D totally.

Since directly editing the lxss user home from Windows software is not supported right now, why not have the lxss filesystem (outside of the /mnt stuff) just be a drive image, similar to the option in RDS in Windows Server 2012 R2 to make user home directories mountable images? That would cure the trouble of being able to move the folder around (since you could just point bash.exe to the image), and also would dissuade users from directly editing files in it (which breaks it).

I mean, users could even do this now by creating the \appdata\local\lxss folder, mounting a vhd to it, and then installing bash.exe directly.

I uninstalled via lxrun /uninstall /full /y but recreated the folder %localappdata%\lxss, created a 20GB NTFS-formatted lxss.vhdx in diskmgmt on my side hdd (W:), and mounted it to %localappdata%\lxss with diskpart's mount command, then reinstalled WSL via bash.exe. So far, it's working.

I have a task set up right now to mount the vhdx on boot via the taskschd.msc running diskpart together with a script as System user, should continue to work after a reboot.

The script:
select vdisk file="W:\lxss.vhdx"
attach vdisk
`assign mount="C:\Users\fpqc\appdata\local\lxss"``

Also, another benefit of this is that you can easily back up your lxss install (if you are going to mess around and try something that might break it), simply by copying the vhdx.

Great, thanks! Haven't tried yet but looks good. Marking as solved.

Since build 14388 the vhdx method did stop working. :(
I have been using an external bash.vhdx for days and attached to an empty %AppData%/Local/lxss folder WSL worked great.
Now when running bash.exe it says Error: 0x80070003

It seems now it tests the lxss folder and if it wasn't created by lxrun.exe then refuses to run.

I hope someone finds another way to export the WSL filesystem outside of the system partition. Compiling a project like Cyanogenmod13.0 (needs +60Gb of disk space) is just impossible for me without it.

ooh good catch man I'm not on 14388 yet but I hope they fix this.

Does Cyanogenmod13.0 compile without issues on DriveFs? (/mnt/d/...)

@benhillis On build 14372 there were some problems on repo sync. #124

I'm going to try now on 14388.

Edit: Same error as 14372. On VolFs repo sync worked well though.

@benhillis eep my whole setup got nuked. I guess I will find a way to get my home folder and configs back >.>.

I managed to move lxss folder to another partition in build 14390. It's not as elegant and flexible as the vhdx method but at least it works.
First uninstall your current WSL with lxrun /uninstall /full. Before installing WSL again you need to move %LocalAppData% folder to another partition and then create in the AppData folder a junction pointing to the new location. mklink /J C:\Users\onoma\AppData\Local E:\Local
After that lxrun /install will work like always.

%LocalAppData% is a folder always being used by the system so you need to move/copy it from "outside". I created another admin user and did it from there.

I haven't tested onomatopellan's new workaround yet, but I'd be inclined to consider this an open issue until Microsoft would start considering and supporting this use-case. Not every SSD-owner will have found this thread. :(

Yes, we need an option to move or install lxss folder in a desired location.

My method is working but it killed Edge browser. Every time I open Edge it crashes because it depends on LocalAppData folder. Also didn't survive to an upgrade to a newer build. Next step will be trying moving the entire AppData folder instead.

I'm trying to understand how lxss folder works. It can't be a junction anymore (thus VHD method wont' work) and only lxrun.exe can create it. Folder can't be copied or moved but can be renamed and like this I have various lxss folders (lxss.xenial, lxss.trusty, lxss.base) with different environments. To change from trusty to xenial I just have to rename lxss.xenial to lxss and it works. So the special attributes of WSL files are conserved in their original lxss folders. And that's what I can't understand. What makes this folder special? There are no reparse points, its attributes are just hidden and system, there aren't alternate data streams either... so where is the special info stored?

I feel your pain as a 100 GB SSD user. I've kicked of a thread with some of the developers to think about how we can support this Post Windows 10 Anniversary Update.

Just so I have the full story, is the install location the problem or would creating a separate VolFs mount on a different volume serve your purpose? Apt packages etc would still end up on your main OS volume but you could use all the features of VolFs on a larger drive.

Hm. I think I could definitely fill some GB just from installing things, so going by that, the ability to allow having the whole thing off the SSD would be nice. I dunno what VoIF stands for though!

Great to hear you are considering this. I'd vote for an entire different install location. And if it was possible to install on a VHDX file it would be the best. Being able to backup an entire WSL environment so easily has been the best feature until build 14388 was released.

All that said as second option mounting VolFs folders on external partitions sounds sweet.

@tycho01 VolFs folders are the / and /home type folders and have linux-like attributes. DrvFs are the /mnt/* folders.

@benhillis Actually, the earlier workaround solution of installing on a vhdx was working really well for me (and apparently a bunch of other people). Not really sure how it broke, but what would be ideal is to fix things so we can do that again (maybe automate it?) as well as allow us to create other vhdx files "formatted" for VolFS use that can be mounted.

I'll vote for this option.
The lxss is killing my disk space :(

@onomatopellan

I might be wrong, but maybe you can consider just create lxss folder under appdata\Local and only link this folder to another directory, so that Edge won't crash? I'm not sure if you link the whole local folder because the bash system requires, or you didn't have the lxss folder before creating the subsystem? (Sorry I just realised you meant that lxss can't be linked? I just tried and it said cannot create link when file already exists)

Although vhdx is more elegant, mklink seems to be faster right? My poor table has very slow disk i/o (I'm using a sd card, which is slow and sometimes windows just can't detect it, maybe someone can help me make it stable), and I do hope I can have a faster way.

After reading this post, I'm considering moving Office 365 (or maybe the whole program files) :) No idea why Edge crashed actually, I thought mklink worked the same way as linux and Edge should put its files wherever the address is, regardless the actual location.

@zidongtuili Exactly, lxss can't be a link anymore. That's why I tried moving and linking Local folder. I think Edge crashed because the method I used to copy the LocalAppData folder wasn't the best. I changed the way I copy the "Local" folder now (I use robocopy after booting to command prompt) and I had better luck. Edge works like it should and WSL installs without problem. Now I only need to know if the link will survive to a new build install. I'll try with next Insider build.

@onomatopellan I tried your solution, use another admin user and robocopy the Local folder to another parition, then made a junction link. Everything seems ok after reboot and I installed WSL successfully. But one day later the system goes wrong. All of the ump apps disapeared and the setting app crashed.
The command i used:

robocopy C:\Users\XXX\AppData\Local D:\Local /e /xj /copyall
mklink /j "C:\Users\XXX\AppData\Local" "D:\Local"

@utick Is that user a Local account or a Microsoft Account? It's weird everything did work and suddenly didn't. Sounds like if Windows changed the drive letter where you stored the Local folder. Is that a fixed partition or a removable one? It also seems you used the old method, creating another user and copying from there in desktop. That method gave me trouble so now I use native Command Prompt.

• Create a new admin local account for testing. Let's call it Test for example.
• Login to Test and see which drive will store the Local folder. In my case is E:
• Now restart to Advanced Startup (Shutdown button -> Restart with SHIFT key pressed)
• Select Troubleshoot -> Advanced Options -> Command Prompt.
• Login to Test and a command prompt window will appear. In this environment drive letters could have changed so we need to know which one is the windows partition and which one is the E: where we want to copy Local folder.
• Type diskpart and then list volume In my case the windows partition is D: and the other partition here is F:
• Type exit to exit from Diskpart. After this type:
• mkdir F:\Local
• cd D:\Users\Test\AppData
• robocopy Local F:\Local /E /COPYALL Make sure there are no errors.
• rename Local Local.old
• mklink /J Local E:\Local This is important, the symlink needs to point to the drive letter you saw on the Desktop, nor the one you see on command prompt.
• exit
  now Continue Windows 10 restart and login to Test and everything should work like always.

EDIT: I forgot something important. After this trick lxrun.exe cant create a new user because it can't access Temp folder. Open an admin CMD and type SET TEMP=E:\Local\Temp pointing to the new Temp location. After that lxrun /install to begin the bash install.

Short all the stuff Microsoft should have implemented in his LxRun tool from the beginning.

I suppose it is possible that the devs at MSFT are simultaneously (a) capable of implementing an entire Linux syscall emulation layer while (b) are oblivious to the fact you can install WSL on another drive with a static tar and a tiny powershell script (or equivalently any of the many LxRun******* related projects).

But... you might want to consider the likelihood of that being the case. And in the off chance it isn't the case that the MSFT devs are oblivious, you might want to reconsider the veracity of any conclusions drawn from false premises. Please use the online communities of those projects to report any problems you may have with their product.

@therealkenc
Sorry it was only just a personal comment. I just wanted to show how much I like the LxRunOffline tool I found. Like in opening post I had my frustration with the installation in %userprofile%\appdata\local\lxss (about 2 years ago). I couldn't use junctions. I searched and searched and didn't found any solution to change the path. And the comment was for what time. Now with this tool I can resuse my old lxss installations.
@DarthSpock your right I didn't make much research recently, I found this tool and wanted to share this information. But thanks link the official way.

Ok maybe comment is a little misleading, but would it have been so hard to have something like lxrun /install /dir in the beginning. I know we have now many other methods including store and lxrun isn't the official way anymore. So sorry I didn't wanted to offend anyone.

Moving WSL distribution is somehow documented in Windows 10 insider build 18305. Use wsl.exe --export export installed distribution. Then use wsl.exe --import with diffenrent folder path to install it in another location.

@Biswa96 I can confirm that this works in the latest 1903 update (build 18362.175).
Thanks for the pointers

if you export then import, how do you get the binary shortcut (ie ubuntu.exe) back, and how do you get it to default to your user account instead of root? :-D

@ericblade Hmm if you had the binary you could run:

DISTRO_BIN.exe config --default-user NEW_USER

But if the binary isn't installed properly after the restore that makes things a bit more complicated...

But if the binary isn't installed properly after the restore that makes things a bit more complicated...

It isn't. This is #3974 (message) and currently in state chirping cricket. Work-around for now is to set the default UID in the registry by whatever means of choice.

That works great, thanks again, therealkenc.

Simplest way i found to have the wsl on another partition:

Create a dynamic vhd and attach it to "C:\Users\USER\AppData\Local\lxss" and now u can install wsl as u normally would or copy your old wsl inside the vhd ... BUT don't forget to mount your vhd

Another way is by using powershell u can manually install the wsl distribution:

Example for installing Ubuntu 16.04:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
New-Item D:\Ubuntu -ItemType Directory
Set-Location D:\Ubuntu
Invoke-WebRequest -Uri https://aka.ms/wsl-ubuntu-1604 -OutFile Ubuntu.appx -UseBasicParsing
Rename-Item .\Ubuntu.appx Ubuntu.zip
Expand-Archive .\Ubuntu.zip -Verbose
cmd
ubuntu1604.exe

FIRST , you create the folder where we want to install the wsl distribution and cd into it
THEN , you download the wsl distribution that u want from the Power Shell using
Invoke-WebRequest -Uri <LINK> -OutFile <distribution.appx -UseBasicParsing
AFTER the download is finished , you rename the file extension from APPX to ZIP and extract it
INSIDE the extracted folder you will have a executable file with the name of the distribution (eg ubuntu1804.exe)
Run the executable file and the installation process will begin

@cbits06 Powershell method works with wsl 2! Thanks!

@cbits06 Thanks you for the Powershell method. It's working perfectly here with WSL 2.
In my case, the appx package download failed (due my shitty Wi-Fi I guess), solution was manually download it and paste it to E:\Ubuntu.

#5044 was closed as a dupe but I'm reposting some of that info because I think there is a bit of a unique ask in that issue.

tldr: the unique ask is to respect Windows 10 storage settings Change Where New Content is Saved and New Apps will Save to.

Is your feature request related to a problem? Please describe.
My C drive is near capacity.

When using WSL + Ubuntu, I ran Add-AppxPackage from my storage drive (D:).

I also previously configured my Windows 10 Storage settings to "Change Where New Content is Saved" including "New Apps will Save to" my storage drive, but I notice the files are put on C: anyway. I would argue this is a bug, but Stack Exchange states it's simply not supported.

Describe the solution you'd like

If I run Add-AppxPackage on a remote drive, the subsystem files are stored on that drive.
From inside subsystem, if I install a package it can be saved to a folder I chose, potentially on another drive.
The two above can be implemented separately. For implementation on WSL side, I think it's easier to continue WSL installation on my main drive, but when I sudo apt-get install unzip, for example, that stuff can be put on my storage drive.

Another way is by using powershell u can manually install the wsl distribution:

Example for installing Ubuntu 16.04:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
New-Item D:\Ubuntu -ItemType Directory
Set-Location D:\Ubuntu
Invoke-WebRequest -Uri https://aka.ms/wsl-ubuntu-1604 -OutFile Ubuntu.appx -UseBasicParsing
Rename-Item .\Ubuntu.appx Ubuntu.zip
Expand-Archive .\Ubuntu.zip -Verbose
cmd
ubuntu1604.exe

FIRST , you create the folder where we want to install the wsl distribution and cd into it
THEN , you download the wsl distribution that u want from the Power Shell using
Invoke-WebRequest -Uri <LINK> -OutFile <distribution.appx -UseBasicParsing
AFTER the download is finished , you rename the file extension from APPX to ZIP and extract it
INSIDE the extracted folder you will have a executable file with the name of the distribution (eg ubuntu1804.exe)
Run the executable file and the installation process will begin

2004 version link
https://aka.ms/wslubuntu2004

Make sure that you're checking out the directory structure as well once downloading the distro with the above method. It appears that the directory structure may have changed, it definitely did for Kali.

Note: I used the wsl-kali-new distro as it was the latest WSL version, but wsl-kali worked as well and utilized a more simplified directory structure. I have not tried this with Ubuntu or any other distro, they may be more simplified.

For example I went to install Kali, using the above method, created a D:\Kali directory:
Invoke-WebRequest -Uri https://aka.ms/wsl-kali-new -OutFile Kali.appx -UseBasicPasring
Rename-Item .\Kali.appx Kali.zip
Expand-Archive .\Kali.zip -Verbose

Open the directory or use the ls command and you will see a few different .appx files:
DistroLauncher-Appx_1.1.9.0_scale-100.appx
DistroLauncher-Appx_1.1.9.0_scale-125.appx

There is one that contains the main Kali.exe file:
DistroLauncher-Appx_1.1.9.0_64x.appx
Rename-Item .\DistroLauncher-Appx_1.1.9.0_64x.appx DistroLauncher_1.1.9.0_64x.zip
Expand-Archive .\DistroLauncher_1.1.9.0_64x.zip -Verbose

cd into this new folder, and install the distro:
.\kali.exe

This installed Kali, prompted me to enter my UNIX username and password, and successfully mounted Kali to my D:\...
username@computer-name:/mnt/d/Kali/Kali/DistroLauncher_1.1.9.0_x64$

bash works as well from PowerShell/cmd.

sudo update && upgrade worked, bundled software worked, and everything is in the root directory of the distro.

Now that I have it working, I'll probably uninstall and see if I can't simplify the directory structure a little more. None of the other DistroLauncher... .appx files contain an .exe file. They seem to have necessary manifest information, but appears redundant to what is present in the .appx file which I expanded and installed. It may be possible to dramatically reduce the directory structure by changing the mount point from within WSL.

Although I haven't tried it yet, the manifest details state that kali.exe is a standalone within it's folder. I think there's a good chance that only that containing folder can be used. I will update when I have a chance to do more work on this.

It's been a while now and there's still no officially-sanctioned way to base the WSL2 on a drive different than the system's C: .

Are there any plans to add that feature at all?

使用 LxRunOffline 可以简单的解决这个问题啊
Using LxRunOffline can easily solve this problem.

我一直在使用 LxRunOffline 管理wsl，目前来看，使用 LxRunOffline 任然是解决这一问题的最好的方法
用 wsl --export 和 wsl --import 这两个命令可以对 WSL 进行打包再自定义目录安装，就相当于转移。我以为这已经是相当完美的解决方案了.直到我发现 LxRunOffline，它可以安装任意发行版到任意目录、转移已安装的 WSL 目录、备份 WSL、设置默认用户和修改环境变量等操作，相反 wsl、wslconfig 这些原生命令确实有点不足

Still no updates on this one after 7 years?!

Edit: The wsl --export and then wsl --import approach actually works, for those who are curious, see this Stack Overflow answer.

I think even if you guys have no intention to add a built-in option for this, you should at the very least document this particular workaround — there's also this PowerShell script that could do it for you.

This issue was opened the same day Harambe died. This day, Roe has already been overturned and we are still trying to move our WSL's from C: to D:

Can simply move installed distro to other location
stop wsl first: wsl --shutdown
Path to distro stored in registry: "Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss{some guid}\BasePath"
move distro to another location and update path in registry.

Can simply move installed distro to other location stop wsl first: wsl --shutdown Path to distro stored in registry: "Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss{some guid}\BasePath" move distro to another location and update path in registry.

'simply', may as well just install linux as the main OS at this point

Can simply move installed distro to other location stop wsl first: wsl --shutdown Path to distro stored in registry: "Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss{some guid}\BasePath" move distro to another location and update path in registry.

'simply', may as well just install linux as the main OS at this point

LMAO