moving Linux filesystem

[KiaraGrouwstra]

I figured I was about to install a bunch of things on my shiny new Linux subsystem, then realized my SSD would soon run out of disk space at that rate. Hoping I could improvise a solution, I tried moving the folder C:\Users\USER\AppData\Local\lxss to my D: drive and creating a (hard) symlink to it from the original location. This backfired though, as I was no longer able to boot bash afterwards (nor after moving it back or disabling/re-enabling the feature), which resulted in either no response (if opened from the start menu) or with Error: 0x8007001f (if called from a command prompt).
I'd be glad to know if anyone has successfully managed to move their Linux subsystem to save SSD space.

[fragtion]

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

[dreyks]

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

[lidangzzz]

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

[fpqc]

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.

[fpqc]

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.

[KiaraGrouwstra]

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

[onomatopellan]

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.

[fpqc]

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

[benhillis]

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

[onomatopellan]

@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.

[fpqc]

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

[onomatopellan]

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.

[KiaraGrouwstra]

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. :(

[onomatopellan]

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?

[benhillis]

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.

[KiaraGrouwstra]

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!

[onomatopellan]

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.

[fpqc]

@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.

[rayncc]

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

[zidongtuili]

@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.

[onomatopellan]

@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.

[utick]

@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"

[onomatopellan]

@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.

[Biswa96]

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.

[transcriptomics]

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

[ericblade]

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

[jsilvermist]

@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...

[therealkenc]

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.

[ericblade]

That works great, thanks again, therealkenc.

[cbits06]

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

[cbits06]

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

[kompolom]

@cbits06 Powershell method works with wsl 2! Thanks!

[R0rt1z2]

@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.

[Vandivier]

#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.

[tomas-light]

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

[heyJonBray]

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.

[Battlesheepu]

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?

[Orange-Jun]

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

[Orange-Jun]

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

[aradalvand]

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.

[washtubs]

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:

[tnikolai2]

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.

[FinalFortune]

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

[R0rt1z2]

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

[thadguidry]

You can now manage distribution locations through a new command line option:

--manage <Distro> <Options...>
        Changes distro specific options.

        Options:
            --move <Location>
                Move the distribution to a new location.

            --set-sparse, -s <true|false>
                Set the vhdx of distro to be sparse, allowing disk space to be automatically reclaimed.

Usage Example:

PS C:\Users\thadg> wsl --manage ubuntu --move F:\wsl_ubuntu
The operation could not be completed because the vhdx is currently in use. To force WSL to stop use: wsl.exe --shutdown
Error code: Wsl/Service/MoveDistro/WSL_E_DISTRO_NOT_STOPPED
PS C:\Users\thadg>

So Upvote 👍 on this comment if you agree this issue can now be closed. Or 👎 and leave a comment why it needs to remain open.

[KptnKMan]

You can now manage distribution locations through a new command line option:

Amazing! Great addition to WSL!

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

If you are using WSL and struggle and complain to edit registry, then literally what are you even doing?