WSL available disk space

[johne53]

About 5 years ago I installed WSL on a Windows 10 machine. It was just out of curiosity really, I've never had much reason to use it. So it's still there on my machine (along with Debian) and they never caused any problem so I just left them there. But now I'd like to look a bit deeper and install some Linux apps - which got me wondering...

How does disk space get allocated to/by WSL? Is it something T would've needed to configure at install time or does WSL allocate space fluidly (i.e. as and when Debian needs more space?)

And is there a bash command I could run to find out how much space it thinks is available?

[chemwolf6922]

You may use wsl df to check out the "allowed" max size (check for mount point / ). By default, it's 1T. However, the actual useable size is determined by how large can the vhdx file grow. That depends on how much actual space is left on the windows drive. By default, that will be the C drive.

[johne53]

Thanks @chemwolf6922 for the quick reply. What's puzzling me is that if I launch Nautilus and click Other Locations it shows an icon saying Computer with a size of about 270GB. And if I open bash and type df that shows me /dev/sdd being the same size.

Which is strange because I don't have any drives that big here!

With a bit of luck I won't be short of space though.

[ELHart05]

Short answer to your two questions: it's fluid, you didn't configure anything at install time, and df -h / is the command.

WSL 2 keeps the whole Debian filesystem inside a single virtual disk file (ext4.vhdx) on your Windows drive (under %LOCALAPPDATA%\Packages\...\LocalState). That disk is dynamically expanding: it grows on demand as Debian actually writes data, so you never sized it up front. It only uses real space on your Windows drive equal to the data actually stored, not its maximum size.

Two things bound how big it can get:

• A maximum virtual size (the cap). On current WSL the default is 1 TB. That's just a ceiling, not reserved space, which is why a df size can look larger than any disk you own.
• Whatever is actually free on your Windows C: drive, since that's where the vhdx physically lives. In practice this is the real limit.

To see what Debian thinks it has, from inside the distro:

df -h /

Size is the current apparent size of the ext4 disk, Avail is what's free. From the Windows side you can run the same without opening a shell with wsl df -h /.

One thing worth knowing before you start installing apps: the vhdx grows but does not shrink on its own when you delete files. If you ever fill it and then clean up, reclaim the space on the Windows side by shutting WSL down and compacting the disk:

wsl --shutdown
# then compact, either via Hyper-V's module (Windows Pro):
Optimize-VHD -Path "<path to ext4.vhdx>" -Mode Full
# or via diskpart:  select vdisk file="<path to ext4.vhdx>"  then  compact vdisk

For just trying out a few Linux apps you won't get anywhere near the limit, so you can ignore all of that and just go.

[ELHart05]

Yes, you can move it, and without reinstalling anything.

The clean way on recent WSL builds is the built-in move command. Close anything using the distro, shut WSL down, then move it wherever you like:

wsl --shutdown
wsl --manage Debian --move "D:\WSL\Debian"

Swap Debian for your actual distro name if it differs (wsl -l -v to check) and point it at whatever drive and folder you want. WSL relocates the ext4.vhdx, updates its own registry entry, and the distro keeps working exactly as before. Nothing is lost.

Since this install is old, your WSL might predate --manage. Check with wsl --version; if --manage isn't recognised, the manual route does the same job:

wsl --shutdown
wsl --export Debian "D:\debian-backup.tar"
wsl --unregister Debian
wsl --import Debian "D:\WSL\Debian" "D:\debian-backup.tar"

One catch with the manual route: after --import the distro logs in as root instead of your normal user. To fix that, edit /etc/wsl.conf inside Debian and add:

[user]
default=yourusername

then wsl --shutdown and reopen. The --manage --move method doesn't have that problem, so prefer it if your version supports it.

If that sorts it out and all good, feel free to mark the thread as answered.

[johne53]

Thanks again @ELHart05 I needed to use the manual route and it kinda worked. One problem is that if I launch nautilus, navigating to Computer/home/ displays the contents of my home folder, but clicking Home (at the LHS) shows an empty folder now.

Also - In the past I could launch nautilus with a command line option that used to let me close bash but nautilus would remain onscreen. I can't quite remember the command but it was something like nautilus &. Could you take a guess at what the command might've been?

[ELHart05]

So first, nothing is lost. This is the root-user catch from the manual route. After --import, the distro logs in as root, so your shell's $HOME is now /root. Nautilus's Home shortcut just follows $HOME, which is why it opens an empty /root, while Computer / home / <you> still shows all your real files. They're safe where they are.

To fix it, set your normal user back as the default. Inside Debian, edit /etc/wsl.conf and add:

[user]
default=yourusername

then from Windows:

wsl --shutdown

Reopen Debian and run whoami to confirm you're your normal user again rather than root. Now $HOME is /home/yourusername and Nautilus Home will point at your files.

For the second question: yes, it was nautilus &. The & backgrounds it so you get your prompt back, but closing the terminal can send a hangup signal to its background jobs and take Nautilus down with it. To fully detach it so bash can close and Nautilus stays up, use either:

setsid nautilus

or

nohup nautilus >/dev/null 2>&1 &

Both survive the terminal closing. (nautilus & disown works too, it just drops the job from the shell so the hangup never reaches it.) Add a path to open straight into a folder, for example setsid nautilus ~/Downloads.

If the Home fix sorts the sidebar out, that wraps up the original question, so feel free to mark it answered.

[johne53]

Sorry to be a pest (it's a long time since I used WSL or Debian) but I've listed the contents of /etc and there's no file called wsl.conf

Also, I can't remember my Debian user name (would it normally be the same as my Windows user name?)

In case it helps, find gives me this output:-

root@MAC-PRO:~# find . name wsl.conf
.
./.bash_history
./.local
./.local/share
./.local/share/tracker
./.local/share/tracker/data
./.local/share/tracker/data/.meta.isrunning
./.local/share/tracker/data/tracker-store.ontology.journal
./.local/share/tracker/data/tracker-store.journal
./.local/share/nautilus
./.local/share/nautilus/scripts
./.local/share/nano
./.local/share/nano/search_history
./.ssh
./.ssh/known_hosts
./.cache
./.cache/tracker
./.cache/tracker/meta.db-shm
./.cache/tracker/parser-version.txt
./.cache/tracker/meta.db-wal
./.cache/tracker/meta.db
./.cache/tracker/ontologies.gvdb
./.cache/tracker/db-locale.txt
./.cache/tracker/db-version.txt
./.dbus
./.dbus/session-bus
./.dbus/session-bus/d0f0959f06704cdd9a721c5acfe80121-0
./.config
./.config/nautilus
./.config/gtk-3.0
./.config/dconf
./.config/dconf/user
./.profile
./.bashrc
find: ‘name’: No such file or directory
find: ‘wsl.conf’: No such file or directory

[ELHart05]

No worries, you're not a pest XD.

The file simply doesn't exist by default, so you create it rather than edit it. That's expected, not a sign anything is wrong.

First, find your Debian username. It isn't necessarily your Windows name, since WSL asks for a separate Linux username when you first set the distro up. The reliable way is to list the home folders:

ls /home

Whatever folder name shows up there is your username (the first account WSL creates gets it). You can double-check with:

getent passwd 1000

which prints that user's line, where the first field is the name.

Then create the file. Since you're currently root, you can write it straight in with no sudo needed. Replace yourusername with what you just found:

cat > /etc/wsl.conf <<'EOF'
[user]
default=yourusername
EOF

If you would rather use an editor, nano /etc/wsl.conf does the same thing.

Then from Windows:

wsl --shutdown

Reopen Debian and run whoami. It should now show your username instead of root, and Nautilus Home will point at /home/yourusername with your files.

[johne53]

That's almost back to normal now. nautilus now shows my Home folder correctly and nautilus& works as expected (without needing disown at the end)

nautilus& and nautilus & disown both show some strange numbers now which I never saw before (the numbers are different each time I launch them...)

[ELHart05]

That's normal job control, nothing is wrong. When you background a process with &, bash prints [1] 12345: the [1] is the job number and 12345 is the process ID, which changes every launch because each new process gets a fresh one. Safe to ignore.

If you would rather not see them, launch it detached and quiet with setsid nautilus >/dev/null 2>&1.

More on how this works: https://www.gnu.org/software/bash/manual/html_node/Job-Control-Basics.html

Sounds like Home is back and Nautilus launches the way you wanted, so if you are happy with it all, feel free to mark this as the answer, thanks

[johne53]

When you background a process with &, bash prints [1] 12345: the [1] is the job number and 12345 is the process ID

If you would rather not see them, launch it detached and quiet with setsid nautilus >/dev/null 2>&1.

Hi @ELHart05 your suggestion about setsid nautilus >/dev/null 2>&1 works fine here. In fact I read a few articles this morning and they all mention about the job number and process ID getting printed if you background a process.. It's a bit strange that I never saw them before but at least it's all working normally again now. Thanks for all your help with this.

[ELHart05]

Glad I helped, anytime

[johne53]

@ELHart05 - HEEEELP... on a different forum I was chatting about WSL and I casually asked if anyone could take a guess at the simpler command I previously used for nautilus to run in the background without showing those numbers. Some lunatic suggested it was probably nohup nautilus&. It didn't seem right but I tried it anyway. But now, whenever I launch any app, a brand new job gets created:-

1. even if I already closed the previous instance - and
2. even after using WSL --shutdown - and
3. even after I re-boot the PC !!!

Given that it survives a re-boot, I guess some secret file must get created somewhere and once created, nohup then takes over the bash terminal for the rest of eternity. Is there any way I can get things back to normal?

[Edit...]
In case I'm getting mixed up, here's what's convincing me that nohup is surviving wsl --shutdown and also re-booting. Prior to ever trying nohup, if I launched nautilus& 4 times and closed it immediately afterwards I'd see printouts looking like this:-

johne53@MAC-PRO:~$ nautilus&
[1] 1935
johne53@MAC-PRO:~$ nautilus&
[1] 1945
johne53@MAC-PRO:~$ nautilus&
[1] 1956
johne53@MAC-PRO:~$ nautilus&
[1] 1966
johne53@MAC-PRO:~$

Notice that while the process ID changes, the job number is always [1]. It only ever changed to [2] if I launched nautilus while another instance was already active. After nohup the same command sequence now looks like this (even after re-booting etc):-

johne53@MAC-PRO:~$ nautilus&
[1] 1935
johne53@MAC-PRO:~$ nautilus&
[2] 1945
johne53@MAC-PRO:~$ nautilus&
[3] 1956
[2]  Done                    nautilus
johne53@MAC-PRO:~$ nautilus&
[4] 1966
[3]  Done                    nautilus
johne53@MAC-PRO:~$

which suggests (to me) that closing nautilus down is no longer stopping the process (or maybe it's now taking a long time for processes to stop?). The guy on the other forum is saying that this shouldn't be happening after a re-boot (i.e. nohup shouldn't survive a re-boot) and therefore it must be some peculiarity with WSL???

[johne53]

[Update...] This morning I remembered that I've a linux distro called Zorin here on a bootable USB stick. I've definitely never used nohup with Zorin so I booted up and ran the same test as above. And the output is exactly what I'm currently seeing (2nd printout above).

And yet I'm certain I used to see the 1st printout 😕

[johne53]

[Edit...] In case I'm getting mixed up, here's what's convincing me that nohup is surviving wsl --shutdown and also re-booting. Prior to ever trying nohup, if I launched nautilus& 4 times and closed it immediately afterwards I'd see printouts looking like this:-

Yes, I think I must have gotten mixed up. I only realised today that any apps started by WSL (e.g. nautilus / firefox etc) show up in Task Manager as usual. So if nohup was surviving a re-boot I'd see the apps in Task manager after re-booting (which I don't).

Sorry for the noise.