WSL2 to can't browse in /mnt/c

[trondhindenes]

Please fill out the below information:

• Your Windows build number: 10.0.18917.1000

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)
  in wsl:
  ls /mnt/c

• What's wrong / what should be happening instead:
  the folder is empty. Should have listed my Users folder etc

[benhillis]

Are there any interesting errors in dmesg?

Can you provide the output of the mount command?

[hadim]

I had the same issue and in my case it was because I added:

[automount]
options = "metadata"

in wsl.conf. I think when using WSL2 you can comment or delete this file.

(then you'll have to restart WSL with wsl --shutdown)

[benhillis]

@hadim - The metadata option should still work with WSL2, I will take a look though.

[hadim]

Is it still relevant? If it is then mounting C drive only works for me when removing this option.

[benhillis]

@hadim - Do you have any output in dmesg? I am unable to repro this locally:

root@BENHILL-VM4:/mnt/c/benhill# cat /etc/wsl.conf
[automount]
options = "metadata"
root@BENHILL-VM4:/mnt/c/benhill# mount | grep drvfs
C:\ on /mnt/c type 9p (rw,noatime,sync,dirsync,aname=drvfs;path=C:\;uid=1000;gid=1000;metadata,access=client,trans=fd,rfd=8,wfd=8)
D:\ on /mnt/d type 9p (rw,noatime,sync,dirsync,aname=drvfs;path=D:\;uid=1000;gid=1000;metadata,access=client,trans=fd,rfd=8,wfd=8)

[hadim]

My bad, I just re-enable the metadata option, restarted WSL and I can mount the C drive...

C:\ on /mnt/c type 9p (rw,noatime,sync,dirsync,aname=drvfs;path=C:\;uid=1000;gid=1000;metadata,access=client,trans=fd,rfd=9,wfd=9)

No idea what was happening before but the C drive wasn't mounted...

[benhillis]

If you are able to narrow down what the issue was, please reopen.

Thanks!

[trondhindenes]

I think my error is different. C is indeed mounted, its just not browsable.
I can do ls /mnt/c/Users/myUserName, but not ls /mnt/c

[trondhindenes]

@benhillis I don't have an option to re-open this but like I wrote I don't think mine and @hadim 's errors are the same.

[edwindijas]

I encountered the same issue. My problem was with my service initializing scripts. I delayed the initializing scripts in task scheduler by 30 seconds and the problem was resolved.

[JoshuaCWebDeveloper]

I just had this problem happen for the second time since converting an instance from WSL 1 to WSL 2 a little over a week ago.

In both cases, the problem happened after attempting to access the /mnt/c directory right after booting Windows. In both cases, the problem was resolved by simply restarting Windows. The first time I was mucking around with the network settings, and so I blamed it on something I did. However, since then, it had been working fine until this morning when the problem happened again; I had made no changes to the environment in the interim.

Running ls -la /mnt/c shows an empty directory, running ls -la /mnt/c/Users returns no such file or directory. I do not have any /etc/wsl* file.

@edwindijas What service initializing scripts are you using? I do indeed have a Windows batch script that is run on logon by the Task scheduler, this batch script calls ifconfig and service ssh start on my ubuntu1604 instance.

[JoshuaCWebDeveloper]

I have been further able to narrow this problem down. Every day this week, when I first start my computer up, this problem has happened, but restarting would fix the problem.

Today I did some more testing. This seems to happen every time Windows is booted after having been previously Shut Down (i.e. the computer was turned off). However, if Windows was merely Restarted (computer stays on), then this problem will not happen. I'm not sure why this would matter, but I have been able to reproduce this on my pc reliably today.

Additionally, I tried disabling the scheduled batch script I mentioned in my previous comment, and it had no effect; ls -la /mnt/c would still return an empty directory if Windows was booted after having been previously shut down. I'm not aware of any other changes I have made in my environment that could be causing this.

[onomatopellan]

@JoshuaCWebDeveloper That sounds a lot like Fast Startup. I always disable it because it's incompatible with dual booting.

[pietrodito]

@onomatopellan Disabling the Fast Startup solves the issue for me

[datocrats-org]

I had the same issue and in my case it was because I added:

[automount]
options = "metadata"

in wsl.conf. I think when using WSL2 you can comment or delete this file.

(then you'll have to restart WSL with wsl --shutdown)

I have similar options in .conf to run docker per these instructions, something in those settings cause the same behavior reported here, which appears to be expected behavior

[ctivanovich]

I encountered this issue as well, and for me, it was because I followed this guide to scheduling a cron job. I guess the start up task on the windows side to launch the cron process at windows start up time somehow short-circuits the mounting operation.

[Garibaldy]

what helped me was to shutdown wsl then run it again

powershell -> wsl --shutdown
powershell -> wsl

then i got it back

[CMiksche]

I have the same issue when i enter

[automount]
options = "metadata"

into /etc/wsl.conf. Restarting the wsl hasn't helped me.

mount | grep drvfs outputs nothing.

I only need the correct file permissions - is there any other way to do this than metadata? (I don't get the right permissions when i leave the /etc/wsl.conf file empty)

[cloudkarma]

I had the same issue, i could not access any of the drives though they were shown ls /mnt,
I had to comment all the lines in /etc/wsl.conf,
hope this helps

[theogtg]

solved by only having

[automount]

in my /etc/wsl.conf. Then running

sudo apt update

in my wsl instance. Solved everything right away!

[florton]

In my case this was due to not having the correct permissions set on my linux user. Solved by running sudo usermod -G sudo [username]

[michaelj-smith]

My issue was a misunderstanding of the automount behavior.

~$ ls -la /mnt/c
total 8
drwxrwxrwx 2 root root 4096 Sep 15 12:39 .
drwxr-xr-x 4 root root 4096 Sep 15 14:04 ..

~$ mount | grep drvfs
C:\ on /c type 9p (rw,noatime,dirsync,aname=drvfs;path=C:\;uid=1000;gid=1000;symlinkroot=/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8)

~$ cat /etc/wsl.conf
[automount]
root = /
options = "metadata"

What threw me is that I had added the automount settings in wsl with the root = / option. For some time both /mnt/c and /c were empty. But after a wsl --shutdown command in PowerShell, the /c root was then mounted correctly.

[jjschweigert]

Since wsl.exe --shutdown seems to be the only true way to get around this issue when it does occur, I have the following command to run the shutdown command then open the windows terminal

powershell.exe -windowstyle hidden -noLogo -NoProfile -command "wsl.exe --shutdown; explorer.exe shell:appsFolder\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App"

You can get the explorer.exe command for any app, such as ubuntu, by using a tutorial like https://www.tenforums.com/software-apps/57000-method-open-any-windows-10-apps-command-line.html

So if you wanted to open ubuntu, just replace the explorer.exe command with the correct command to open Ubuntu. Then you can create a new shortcut and paste the full powershell command in and then set the shortcuts icon to whatever app icon you need.

For instance, I set the windows terminal icon for the shortcut and pinned it to the taskbar, you can see when I run it a seperate icon shows on the taskbar for the running windows terminal window vs the shortcut which does not show a running status.

[CliffHan]

I met this problem too, on windows 10 home 2004, version 19041.572
At first I guess maybe it's caused after windows sleep or hibernate.
Now it seems I met this every time after system boot. Need "wsl --shutdown" to make /mnc/c work.

[mike-usa]

I met this problem too, on windows 10 home 2004, version 19041.572
At first I guess maybe it's caused after windows sleep or hibernate.
Now it seems I met this every time after system boot. Need "wsl --shutdown" to make /mnc/c work.

As a new WSL user, I'm not too versed on the documentation, so I don't know if this is expected or not.

I concur that every time I shutdown/restart the Windows PC, /mnt/c (in the WSL terminal) is no longer connected. Issuing a wsl --shutdown from PS/Command Prompt and then starting WSL back up will remount the drives.

1. Is this expected behavior?
2. Does it unmount because WSL is a HyperV?
3. Also noted, the wsl does not appear in File Explorer (under Network) until typing \\wsl$ in the address bar; is there a way to automate that? -- I've added my WSL distro to the Quick Access to give it a GUI. I haven't found any documentation to list on startup.

[useafterfree]

If you compiled a custom kernel be sure that VIRTIO is set:

CONFIG_VIRTIO_FS=y

[MueR]

what helped me was to shutdown wsl then run it again

powershell -> wsl --shutdown
powershell -> wsl

then i got it back

This fixed it for me. Thank you!

[lolo9538]

Had the same issue, restarting wsl solves it but the final solution for me was to increase the delay of my windows task that automatically starts wsl at windows startup.

[Sebazzz]

I believe this also occurs when you have run wsl --update on an older Windows 10 installation (like 21H2). It apparently installs a Windows 11 WSL update which uses a different way of communication between host and WSL, so the drives cannot be mounted.

[benhillis]

This issue is quite old, could somebody who is experiencing this please provide /logs?

1. sc stop wslservice
2. start collecting logs
3. repro issue
4. Add the below test to %userprofile%\.wslconfig

[wsl2]
virtio9p=false

6. wsl.exe --shutdown
7. attempt to repro issue, do the drives mount now?
8. stop collecting logs

[microsoft-github-policy-service]

Hello! Could you please provide more logs to help us better diagnose your issue?

To collect WSL logs, download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The scipt will output the path of the log file once done.

Once completed please upload the output files to this Github issue.

Click here for more info on logging

Thank you!

[Sebazzz]

This issue is quite old, could somebody who is experiencing this please provide /logs?
start collecting logs

I presume you specifically mean using collect-wsl-logs.ps1, right?

[benhillis]

Correct, instructions above.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any author activity for the past 7 days. If you're still experiencing this issue please re-open it.

Thank you!

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any author activity for the past 7 days. If you're still experiencing this issue please re-open it.

Thank you!