Could not access starting directory \\wsl$\Ubuntu\home error 0x8007010b

[SGrima1]

Windows Build Number

Version 10.0.19041.985

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.4.72

Distro Version

20.04

Other Software

Visual Studio Code 1.51.1 connected to Ubuntu

Repro Steps

opening ubuntu on windows terminal preview

Expected Behavior

access to wsl

Actual Behavior

[error 0x8007010b when launching `wsl.exe -d Ubuntu']
Could not access starting directory "//wsl$/Ubuntu/home/SAGRI"

Diagnostic Logs

No response

[SGrima1]

[cggonzal]

similar problem on 18.04:

[cggonzal]

I was able to solve this by going into the windows terminal settings, going to the ubuntu profile, and ticking the "Use parent process directory" box. No idea why that worked. It's also worth noting that this occurred to me right after a reboot.

[hi7ee5h]

Just to reiterate, I was having the same issue. This is specific to terminal right now. Running just wsl.exe on powershell works fine and ticking the "Use parent process directory" box in terminal settings seems to have fixed it for me too.

[seapagan]

I was able to solve this by going into the windows terminal settings, going to the ubuntu profile, and ticking the "Use parent process directory" box. No idea why that worked. It's also worth noting that this occurred to me right after a reboot.

Perfect, just had the same issue and the above worked for me - either run in cmd prompt or tick the above setting. Lifesaver!!

I have several WSL distributions, need to tick this for all of them if using Windows Terminal. Must have been some sneaky stealth update last night?

Edit again: This seems to happen if you have a custom startup directory - I did since I don't want to start my Linux in the windows %USERPROFILE% every time. However, If I tick the box, then untick and set the "\\wsl$\Ubuntu\blahblah\home" path to my home directory manually again it all works as before, and I start up in the correct (Linux) home dir.

[pradoz]

Edit again: This seems to happen if you have a custom startup directory - I did since I don't want to start my Linux in the windows %USERPROFILE% every time. However, If I tick the box, then untick and set the "\wsl$\Ubuntu\blahblah\home" path to my home directory manually again it all works as before, and I start up in the correct (Linux) home dir.

Thanks. This worked for me.

I added a few lines to my .zshrc/.bashrc that references my %USERPROFILE% variable. If we end up there, navigate to where we want the default to be instead. Replace ~ with your desired start directory.

if [[ $(pwd) == /mnt/c/Users/mostlikely-your-pc-name ]]
then
    cd ~
fi

[mhbig]

I had the same problem.
It seems that the directory path notation has changed from slash to backslash.
Before: //wsl$/linux-distro/home/user
After: \\wsl$\linux-distro\home\user

[freekvh]

I had the same issue, ticking "Use parent process directory" indeed fixes the described error but starts my shell in /mnt/c/WINDOWS/system32 which I don't like. Manually setting it to:

//wsl$/Ubuntu-20.04/home/linuxUsername

Sets the start dir to my Linux user's home dir ~/ as it should be.

[mohlatif227]

I was able to solve this by going into the windows terminal settings, going to the ubuntu profile, and ticking the "Use parent process directory" box. No idea why that worked. It's also worth noting that this occurred to me right after a reboot.

Thanks a lot, it did work for me.

[nikoandpiko]

I was able to solve this by going into the windows terminal settings, going to the ubuntu profile, and ticking the "Use parent process directory" box. No idea why that worked. It's also worth noting that this occurred to me right after a reboot.

Worked for me, but it started me on System32. Went back into settings and unchecked "User parent process directory". Loaded another tab and it is back to working normally as it did previously with the correct profile loaded.

[ssaroshhasan]

Just go to Windows Terminal>Settings>Ubuntu and replace the starting directory field with Z:\home\username (replace Z: with whatever drive your WSL is mapped on and username with the relevant username/folder name).

[jespadas]

Edit again: This seems to happen if you have a custom startup directory - I did since I don't want to start my Linux in the windows %USERPROFILE% every time. However, If I tick the box, then untick and set the "\wsl$\Ubuntu\blahblah\home" path to my home directory manually again it all works as before, and I start up in the correct (Linux) home dir.

Thanks. This worked for me.

I added a few lines to my .zshrc/.bashrc that references my %USERPROFILE% variable. If we end up there, navigate to where we want the default to be instead. Replace ~ with your desired start directory.

if [[ $(pwd) == /mnt/c/Users/mostlikely-your-pc-name ]]
then
    cd ~
fi

This one works for me, better to start at home directory.

[alecthegeek]

I ticked "Use parent process directory" but left command line as wsl.exe ~ -d Debian and no further changes were required.

Thanks for the info

[bn-l]

I was able to solve this by going into the windows terminal settings, going to the ubuntu profile, and ticking the "Use parent process directory" box. No idea why that worked. It's also worth noting that this occurred to me right after a reboot.

Just adding another voice here. Had the same problem and this worked for me.

[pcgrejaldo]

I ticked "Use parent process directory" but left command line as wsl.exe ~ -d Debian and no further changes were required.

Thanks for the info

Yeah, this worked for me!

[Andrew-J-Larson]

I ticked "Use parent process directory" but left command line as wsl.exe ~ -d Debian and no further changes were required.

Thanks for the info

That's very useful, I like this option, rather than setting the path manually. Hopefully the Windows Terminal will allow using linux shortcuts sometime?

[DHowett]

startingDirectory must be a valid Windows path -- either to the WSL share or to an actual windows path. Sorry.

[DHowett]

If \\wsl$ is failing, this is a WSL bug.

[bonovski]

The problem seems to be that Windows Terminal is looking for the startup directory while wsl.exe hasn't even started, hence it can't open the startup directory.

[swebs]

From my experience (also Windows Terminal Preview), it seems there was nothing wrong with my original settings, but I needed to delete the custom starting directory, successfully start my WSL instance, close it, then put back the same custom starting directory and it worked again.

[bonovski]

From my experience (also Windows Terminal Preview), it seems there was nothing wrong with my original settings, but I needed to delete the custom starting directory, successfully start my WSL instance, close it, then put back the same custom starting directory and it worked again.

I did too, but once I rebooted my PC the error appeared again.

[heitormagaldi]

This bug show up in my terminal today and fixed then using 'windows terminal' configuration menu and setting the correct path. So mad, how or who did change "path inicial"? Windows Update did this?

[DHowett]

You did, Terminal just ignored you until 1.8.

[swebs]

I can confirm that the problem also recurs for me when I reboot. This time I solved it by starting wsl from PowerShell in Terminal Preview (it started up in %USERPROFILE% rather than my custom location). Then I opened a wsl Terminal tab directly and it correctly opened in my custom location.

[craigloewen-msft]

This error is related to your starting-directory setting in Windows Terminal. If the starting directory value is invalid, you'll see this error.

If you'd like to start up in WSL paths please use \\wsl$\ to do that. For example to start in my home directory in Linux I set my starting directory to be \\wsl$\home\caloewen\ or I could set my command line for my WSL profile to be wsl.exe ~.

I'll close this issue out as it's an expected behaviour.

[swebs]

@craigloewen-msft I don't think this should be closed. As far as I know, everyone on this thread has a correctly specified starting-directory it just doesn't work anymore in Windows Terminal Preview until after you start wsl once via some other means after a reboot. My starting-directory is \\wsl$\Debian\home\swebs for example and I have this problem.

[craigloewen-msft]

You're right @swebs ! My apologies for the comment above and closing this issue out early, I just had a quick call with @DHowett and I can add some clarity here:

This error can be caused by two things: An incorrectly formatted starting-directory format, or if the path that starting-directory is querying fails. The latter could happen when you're using \\wsl$\ in your starting-directory value as there seems to be an intermittent bug where querying \\wsl$\ paths sometimes fails.

This behaviour has only shown up now as the 'on starting directory error' behaviour in Windows Terminal changed in version 1.8. In that version it now fails on start up if the starting-directory fails, rather than putting you in your %USERPROFILE% directory which caused inconsistent start up locations.

On the WSL team we'll look into \\wsl$\ queries failing (and I'll reopen this issue to track that). In the meantime if you're seeing this a lot I would recommend using wsl.exe ~ in your command line in Windows Terminal to start up in your home directory in Linux, or if you are on the latest Insider builds you can use wsl.exe --cd <Directory> to start up in specific paths (check usage with wsl --help). Thanks!

[Gorthog]

I was not happy with Files Explorer (come on, no tabs in 2022?), so I used this replacement:
https://www.microsoft.com/store/productId/9NGHP3DX8HDX

It also allows to work around the "Open in Windows Terminal" problem, because you can supply the actual command.
Clicking this will open the configuration file:

And then you can add:

{
      "name": "Windows Terminal",
      "path": "wt.exe",
      "arguments": "-p PowerShell -d .",
      "icon": ""
    }

Which will open Windows Terminal with profile name PowerShell and in the current directory

[mkantautas]

I'm from 2022-02-15 - windows 11 . /home/{$userName}/sites in JSON file works.

[BorkforceOne]

This is definitely still an issue on my laptop running Windows 11 Home OS Build 22000.593.

Using the workaround specified in #6995 (comment) helps with the issue, but as another poster states breaks the context menu option :(

Anything else that can be done? It seems that visiting the Linux directory in file explorer kicks it into working again until rebooting. Really frustrating.

[BtbN]

Ever since the Terminal supports just writing "/home/btbn" into the starting directory field, I didn't have the issue anymore.
Have you tried that?

[BorkforceOne]

Yeah I tried that as well :/ still no dice for me. Thanks for the suggestion though!

[phil-blain]

@BorkforceOne on my side, If my WSL distro is already started (i.e. if I run wsl from PowerShell), then opening a tab with the "WSL" profile from Windows Terminal works if I set startingDirectory to //wsl$/Ubuntu-20.04/home/philippe/. It's only if the distro is not already running that it does not work.

I also learned that if a service is running in the distro, you can log out and it will stay running in the background. So you can do, from Powershell/Command Prompt:

wsl
sudo service cron start
exit

and the distro is still running in the background, and my WSL Windows Terminal profile works. So I did the following:

1. Edit the sudoers file through sudo visudo to allow running sudo service cron start without providing a password
2. Create a batch script that does wsl sudo service cron start
3. Create a shortcut to that batch script in shell:startup so that it runs when I log into my session

This should work with "Open Windows Terminal here" if your WSL profile is your default profile, and it also makes the "Duplicate tab" command open a new tab in the current directory as long as PROMPT_COMMAND is correctly set.

This is on Windows 1909, Windows Terminal 1.11.3471.0.

[AlonsoK28]

For me the issue was produced when I provide incorrectly path param example: wt -d % and the correct format is wt -d %d

Then Windows Terminal was generating system path with incorrectly format example: D:\Documents\dev\my-path\% with a % char at the end of the string

[dom96]

Had the same problem with the "Starting Directory". Reason for it was that I was setting it on a profile which ran ubuntu2204.exe (no idea why this gets auto added when it's buggy like this), but using the other profile which runs C:\WINDOWS\system32\wsl.exe -d Ubuntu-22.04 works just fine.

[DHowett]

no idea why this gets auto added when it's buggy like this

This is something that will need to be raised with Canonical! Their built-in profile json "fragment" tells us to add it.

[dom96]

What's the best way to let them know?

[leog91]

Same problem,

W11 Pro - 22H2
Ubuntu 22.04.1 LTS

hacky fix here,

starting in windows user folder

Settings> Ubuntu>

Command Line
wsl.exe -d Ubuntu --cd ~/../../../mnt/c/Users/<yourUser>/

Starting directory empty (Use parent process directory)

[DHowett]

That seems unnecessarily complicated. You could also just change it to wsl.exe -d Ubuntu. Then the startingDirectory setting will work normally.

[Kolobamanacas]

I have similar issue

[error 2147942667 (0x8007010b) when launching `"C:\Program Files\PowerShell\7\pwsh.exe"']
Could not access starting directory "Microsoft.PowerShell.Core\FileSystem::\\wsl.localhost\Ubuntu\home\usr\projects"

and it seems like I've read all the thread and I hope I didn't miss any solution cause nothing helps in my case. :(

• I have Ubuntu profile's (which I actually don't use) starting directory set to "Use parent directory".
• I have PowerShell (not Windows PowerShell) profile's starting directory set to "%USERPROFILE%".
• New PowerShell tabs open without an issue.
• But I want all tabs to preserve paths I was located at in every tab, when I reopen Terminal, so I've added the following code to my PS profile:

function prompt {
    $loc = $($executionContext.SessionState.Path.CurrentLocation);
    $p = Split-Path -leaf -path (Get-Location)
    $p = "$p> "
    $p += "$([char]27)]9;9;`"$loc`"$([char]27)\"
    return $p
}

Every time I reopen Terminal, each tab where I was located inside \\wsl.localhost\* fails with the mentioned error. Could someone have any idea what could I also try to fix this behavior?

[DHowett]

The giveaway here is that the path starts with Microsoft.PowerShell.Core\FileSystem::. That means it's actually a powershell internal path!

In your OSC9;9 location report from your PS profile, you should actually use (...).CurrentLocation.ProviderPath. That will return the real on-disk path.

[Kolobamanacas]

The giveaway here is that the path starts with Microsoft.PowerShell.Core\FileSystem::. That means it's actually a powershell internal path!

In your OSC9;9 location report from your PS profile, you should actually use (...).CurrentLocation.ProviderPath. That will return the real on-disk path.

You've saved my day! It took me a while, but now my Docker/WSL/Terminal bundle works as (in my opinion) it should. Thanks a lot!

[DHowett]

Happy to help! Let me make sure that we don't have the version in our documentation that is busted. 😁

[darkvertex]

Something else I've noticed when using OSC9 codes is if I was on a WSL shell and ssh somewhere where I've configured my PS to use OSC9 also, is that when I kill Windows Terminal and it comes back, it remembers and it tries to cd into the path that only existed remotely, and so it errors.

I guess I need to disable OSC9 on remote shells on my setup. 🤔

[DHowett]

@Kolobamanacas thanks again for pointing this one out; I fixed our documentation up in MicrosoftDocs/terminal#623 😄

@darkvertex Alas, that's one of the worst parts of this whole "working directory" thing. I wish we could restore remote working directories!

[douglasg14b]

Yeha, startup directory works till you actually want to access the non-wsl filesystem,

\\\\wsl$\\Ubuntu-22.04\\mnt works but \\\\wsl$\\Ubuntu-22.04\\mnt\\c causes it to crash with [process exited with code 4294967295 (0xffffffff)]

No suggestions actually seem to work here, or anywhere.

There are so many threads, and no one in any of them has a solid answer to how to change the startup directory. Just piles of "try this" changes that don't actually work.

The docs should really be covering this.

[oniubi]

I had the same problem. It seems that the directory path notation has changed from slash to backslash. Before: //wsl$/linux-distro/home/user After: \\wsl$\linux-distro\home\user

I also encountered the same problem. How did you finally solve it?

[digininja]

I installed Ubuntu as the host OS instead of windows, means I don't have to worry about the problem any more.

…

On Mon, 3 Apr 2023, 10:32 ligang, ***@***.***> wrote: I had the same problem. It seems that the directory path notation has changed from slash to backslash. Before: //wsl$/linux-distro/home/user After: \\wsl$\linux-distro\home\user I also encountered the same problem. How did you finally solve it? — Reply to this email directly, view it on GitHub <#6995 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA4SWMQZBLI3BUVV6ISQVLW7KKLDANCNFSM45SJMOSQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[AlexMAS]

The easiest way is to specify the starting directory using ~/.bashrc.

Just open Terminal and define your path:

echo cd /your/start/directory > ~/.bashrc

Then restart it and ejoy.

[BtbN]

The easiest way is to specify the starting directory using ~/.bashrc.

Just open Terminal and define your path:

echo cd /your/start/directory > ~/.bashrc

Then restart it and ejoy.

Again, that will completely break the ability to open your terminal in any other starting directory than your homedir.
So that's not a good solution. And it'll potentially also break other tools/scripts that source bashrc.

[RedBaron1918]

i found one way to change starting directory for Ubuntu. first open Json file in settings, and then add this line:

"commandline": "wsl.exe --cd C:/Users/yourProfile -d Ubuntu-22.04"

[BtbN]

Doesn't that again break the ability to "Open Terminal here" from the context menu of directories?

[Gab01230]

I had a similar problem.
I went to the settings.json file et it appears that the good and available Ubuntu had the parameter "hidden: true,".
I just turned it to false and everything went fine.