"Invalid argument" when executing Windows commands on Ubuntu 20.04

[gAllegr]

Environment

Windows build number: 10.0.19041.572
Your Distribution version: Ubuntu 20.044
Whether the issue is on WSL 2 and/or WSL 1: WSL 2

Steps to reproduce

WSL logs:

Expected behavior

When I run code . inside the root path or some subfolder of linux, VS Code on Windows should be opened, just like it happen when I run the command from the mount folder.

Same for the explorer.exe command (and all Windows commands). When I run them from root or a subfolder, the command should be executed.

Actual behavior

The system print me back an error saying Invalid argument

Note: I searched in previous issues for some help on how to solve this, but didn't found how to

[licanhua]

Are you with ARM device?

[gAllegr]

No, it's a x64

[gAllegr]

Hello, I see no answers. If other info are required in order to identify the reason of this behavior, just name them and I'll provide as soon as possible.

[ropez]

@gAllegr I have the same problem. Did you figure out a solution?

[gAllegr]

@gAllegr I have the same problem. Did you figure out a solution?

Unfortunately no

[victoryc]

I am facing the same problem. Wondering why was this issue closed. The issue linked to above was also not resolved.

[tyronexj]

I am facing the same problem. at startup, all good

$ /mnt/c/WINDOWS/system32/cmd.exe

Microsoft Windows [Version 10.0.19042.844]
(c) 2020 Microsoft Corporation. All rights reserved.

after run docker login

$ /mnt/c/WINDOWS/system32/cmd.exe

/mnt/c/WINDOWS/system32/cmd.exe: Invalid argument

[drzdbd1]

Facing the same issue. WSL used to work fine, not sure how long ago after a round of windows update, all windows commands executed in WSL started to throw "Invalid argument" error.

[sfailor]

I am encountering the identical problem

Windows version: 10.0.21337 Build 21337 WSL 2 Ubuntu 20.04.2 LTS

[sfailor]

This appears to be the same issue as #4260

[benyaminl]

I find a work arround for now using bash/ash shell, by mounting the folder as disk drive see https://github.com/microsoft/WSL/issues/5718#issuecomment-671035212 to mount the network location as drive (on insider should be wsl.local)

You can create file on ~/.local/bin for cmd for cmd command, for ash change first line to #!/bin/ash

#!/bin/bash
cwd=$(pwd)
if ! echo "$cwd" | grep -q "/mnt/"; then
    cd /mnt/c/
    param="cd /d Z:$cwd"
    if [ ! -z "$@" ]
    then
       param=$param" && $@"
    fi
    cmd.exe /K "$param"
else
    cmd.exe /K "$@"
fi

for powershell you could create psh file, change #!/bin/bash to #!/bin/ash if you using ash shell/alpine

#!/bin/bash
cwd=$(pwd)
if ! echo "$cwd" | grep -q "/mnt/"; then
    cd /mnt/c/
    param="cd Z:$cwd; powershell "
    if [ ! -z "$@" ]
    then
       param=$param" -c $@"
    fi
    powershell.exe -c "$param"
else
    powershell.exe -c "$@"
fi

for git on windows/for windows

#!/bin/ash
cwd=$(pwd)
if ! echo "$cwd" | grep -q "/mnt/"; then
    cd /mnt/c/
    param="cd /d Z:$cwd"
    param=$param" && git $@ & exit"
    cmd.exe /K "$param"
else
    cmd.exe /K "git $@ & exit"
fi

then make the executable

chmod +x /home/<your username>/.local/bin/*

Then after that on ~/.bashrc you could add path

PATH=$PATH":/home/<your username>/.local/bin"

If you want to test the change run source ~/.bashrc

if your're on ash/alpine write to ~/.profile

I hope this workarround help a while, I test it on Fedora WSL 34 and Alpine WSL.

Hope the wsl team could fix this problem. Hopefully, because this reproducable even on insider with new ISO which make me insane :'(

the result should be like this

BEN-TP-X220:~$ cd .ssh
BEN-TP-X220:.ssh$ pwd
/home/benli/.ssh
BEN-TP-X220:.ssh$ cmd

Z:\home\benli\.ssh>exit
BEN-TP-X220:.ssh$ cmd echo abc
ash: abc: unknown operand

Z:\home\benli\.ssh>exit
BEN-TP-X220:.ssh$ cmd 'echo abc'
abc

Z:\home\benli\.ssh>exit
BEN-TP-X220:.ssh$ psh "echo abc"
abc
BEN-TP-X220:.ssh$ psh
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

PS Z:\home\benli\.ssh> exit
BEN-TP-X220:.ssh$ git status
fatal: not a git repository (or any of the parent directories): .git
BEN-TP-X220:.ssh$ ls -al ~/.local/bin
total 20
drwxr-sr-x    2 benli    benli         4096 Jul 19 18:57 .
drwx--S---    4 benli    benli         4096 Jul 19 17:47 ..
-rwxr-xr-x    1 benli    benli          225 Jul 19 18:53 cmd
-rwxr-xr-x    1 benli    benli          247 Jul 19 19:04 git
-rwxr-xr-x    1 benli    benli          249 Jul 19 19:07 psh
BEN-TP-X220:.ssh$

I can did this because strangely it works on /mnt/c/ directory, at least the windows exe work on windows partition.

[kevinsullivan]

UPDATE: I updated Windows 10 Home to Windows 10 Education (which is Windows 10 Enterprise plus some educational cruft). I uninstalled and reinstalled WSL 2 and Ubuntu 20.04 LTS. THE PROBLEM PERSISTS.

ORIGINAL POST:

I wish I were equipped to help. All I can do is to further confirm the problem.

Edition: Windows 10 Home (I know, but it's supposed to work now; and essentially all university students using Windows are using Windows 10 Home on a personal laptop, so that's what we have to target here.) Version: 21H1 OS Build: 19043.1151 (right up to date)

One bit of evidence I can offer: Replacing Ubuntu 20.04 LTS with 18.04 doesn't help.

Some kind of guidance / repair is urgently needed here (at least by me); I was planning on having this working by the time classes start at a University in just a few weeks. Again, deep apologies, but I'm not equipped to resolve the issue on the WSL / Ubuntu side. Any kind of update would be extremely helpful!

[RandomGHUser]

Same issue here running Debian WSL2 - I can invoke commands at first open, but after running a few commands, they end up stating "Invalid Argument". Also, WSL2 seems to forget where the current working directory is sporatically. I have a rust program calling env::current_dir() at different times in it's lifecyle, and the command eventually fails (not at it's first invocation, but when called in a later method). It will then completely fail on any subsequent execution, until I create a new terminal.

[byoung4]

I have the same issue, but I have verified that it only happens when my pwd is a network drive.

Example:

$ echo test | clip.exe  # this works OK
$ sudo mount -t drfvs '\\path\to\network\drive' /mnt/example
$ cd /mnt/example
$ echo test | clip
/mnt/c/WINDOWS/system32/clip.exe: Invalid argument

As a workaround, make a shell script called clip and place it somewhere in your path. This seems to work.

#!/usr/bin/bash
curdir=$PWD
cd /
cat | clip.exe
cd $curdir

Now you can just do

$ echo test | clip

[dresch86]

I am running Windows 11 Pro and encountered this same issue. It was working fine at first, but suddenly stopped. As a workaround, I found the following command from the docs to work from the Windows cmd prompt (https://code.visualstudio.com/docs/remote/wsl):

code --remote wsl+<distro name> <path in WSL>

I am wondering if a recent update changed the way paths are handled. I did not notice the remote server was reinstalled in WSL after issuing the above command.

[bartdorsey]

I have a new piece of information. Windows Terminal was recently changed to let you specify a linux path as the starting directory. When I open Ubuntu-20.04 with my Linux path in there, I get the Invalid Argument errors. If I leave it the default of %USERPROFILE% then it works fine. I think under the hood Windows terminal is using the new command line argument:

--cd <Directory>
        Sets the specified directory as the current working directory.
        If ~ is used the Linux user's home path will be used. If the path begins
        with a / character, it will be interpreted as an absolute Linux path.
        Otherwise, the value must be an absolute Windows path.

If I try this from Powershell, if I do "wsl --cd /home/username" then it can't run Windows executables.

But if I launch a wsl without the --cd, then it works.

[bartdorsey]

Interestingly WSL is in this state almost everytime I start my computer.

If I do a wsl --shutdown then the problem goes away wether or not I use --cd or not.

[jazad1089]

Add VSCode to the path this solved to me.

[razem-io]

UPDATE Better solution here: https://github.com/microsoft/WSL/issues/6170#issuecomment-1117689071

---

I have this issue sometimes. Not yet sure why. It's because the wsl network drives aren't mapped correctly. So the path then won't work and this is why it is an Invalid argument. The path can simply not be resolved. A fast fix in cmd or ps shell:

wsl --shutdown
wsl

[sbkpilot1]

This has something to do with .git, whenever I do a code . from a directory under Git I get the Invalid Argument, however when I do it from any other folder it works just fine!

Edit - I believe the cause of this was CRLF line endings in the Git metadata files, What I did was deleted my GIT repo and cloned it again into my Linux filesystem using the native Linux client of Git so it creates the proper LF line endings, No more issues starting VS Code.

[vitamin7]

It's definitely have something to do with path. Here is an easy reproducible workaround: Starting test (can be any directory, or even without specifying directory):

wt nt wsl --cd /

Inside WT:

user@host:/$ ping.exe
/mnt/c/WINDOWS/system32/ping.exe: Invalid argument
                                                  user@host:/$ cd .
user@host:/$ ping.exe

Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]

Note: It's just necessary to issue a 'cd' command. But not necessary to actually change the directory. This is not environment related, as the only difference is "OLDPWD". Setting it explicitly doesn't work.

WT version 1.12.3472.0 O/S Ubuntu 18.04 WSL version 2

[muratcanakcay]

I'm faced with the same problem of getting Invalid Argument. It's unbelievable that the issue has not been resolved after almost 1.5 years.

And then there's also the issue with not being able to access the network drive under \\wsl$ from Windows File Explorer unless you map it to e.g. Z:\ drive. I don't know if they're related but there are many issues opened related to this, too.

[epigramx]

I got this bug after I installed 11 over 10. I noticed something interesting but very weird and hard to debug. If I'm in root's home or / the error happens but if I cd to /mnt/c it goes away (!).

[nathonius]

I see this pop up seemingly randomly. Doing a wsl --shutdown and restarting my terminal fixes it for the next hour or two.

[luismramirezr]

I created a simple script and added a symlink to replace the normal code:

#!/bin/bash

current_working_directory=$(pwd)
vs_code_directory="/mnt/c/Users/<YOUR_USER_NAME>/AppData/Local/Programs/Microsoft VS Code/bin"
param="$1"

cd "$vs_code_directory"
$(./code "$current_working_directory/$param")
cd "$current_working_directory"

It works for me for what I need (just open VSCode loading a folder or file)

[yutsuo]

Had this problem lately when trying to call vscode on WSL2.

Then one day I was looking at my Task Scheduler when I noticed this task:

I didn't create it. Maybe Docker Desktop did?

Anyway I disabled this task and one reboot later, voilá, problem solved.

[wzis]

I tried to copy the chrome.exe from the Windows "Program Files" directory to /var/tmp/, then run it , got the same issue, why: root@DESKTOP-R0EA0CF:/home/gwz/sec# cp /mnt/c/Program\ Files/Google/Chrome/Application/chrome.exe /var/tmp root@DESKTOP-R0EA0CF:/home/gwz/sec# root@DESKTOP-R0EA0CF:/home/gwz/sec# root@DESKTOP-R0EA0CF:/home/gwz/sec# /var/tmp/chrome.exe /var/tmp/chrome.exe: Invalid argument root@DESKTOP-R0EA0CF:/home/gwz/sec# But if I run the /mnt/c/Program\ Files/Google/Chrome/Application/chrome.exe, it's ok.

[razem-io]

Had this problem lately when trying to call vscode on WSL2.

Then one day I was looking at my Task Scheduler when I noticed this task:

I didn't create it. Maybe Docker Desktop did?

Anyway I disabled this task and one reboot later, voilá, problem solved.

Finally. Thank you so much! My task had a different name "Start ArchLinux WSL" but same effect. Now it needs a bit longer to start initially, but the error is gone. No idea why this task is there. It would be strange if this is docker desktop related. It uses a different WSL.

[yutsuo]

It could be the Docker Desktop option to integrate to the default WSL distro, available at the Resources tab:

Maybe it creates the task to force WSL to startup together with Docker Desktop.

By default the WSL distro does not start automatically.

[epigramx]

I did not have docker installed when I got the issue. It occurred here after installing 11 on 10. For an unknown reason the issue is gone now as if something autoupdated it or as if a scheduled task fixed it.

[NotTheDr01ds]

Finally. Thank you so much! My task had a different name "Start ArchLinux WSL" but same effect. Now it needs a bit longer to start initially, but the error is gone. No idea why this task is there. It would be strange if this is docker desktop related. It uses a different WSL.

Were/are you running Distrod? It sounds like Distrod creates a startup task like that.

[wzis]

Please check this, our software can make passwd file have the capabilities to anti-software-based attacks on Linux. We also have Solaris, AIX version of the security software. Basically with our service, we can make almost any OS command on Linux/AIX/Solaris have the capabilites to combat software-based attacks.

[wzis]

Otherwise, if you get this kind of attack: info can't be secure.

[Biswa96]

May I ask what that program is?

[wzis]

Which one? in the 2nd picture？It's the trssh.sh which when you ran it, it will run in the background. As you can see, we also have the trsudo.sh which is used for demo to capture the users entered password for sudo.

[Biswa96]

I mean the program that creates the window with tabs.

[wzis]

putty-nd

[nathonius]

@wzis I don't see how any of that is relevant to this specific issue, but maybe I'm just not understanding?

I haven't seen this error since I reset my home directory in Windows Terminal back to the default for the WSL profile. I'm not sure why that would cause this, but it seemed to be the secret sauce for me.

[wzis]

I found it's not all Windows commands will have the error, I copied the write.exe, to /var/tmp and ran it, no issue. So only some commands will get the problem, reason is not known.

[kforeverisback]

UPDATE Better solution here: #6170 (comment)

I have this issue sometimes. Not yet sure why. It's because the wsl network drives aren't mapped correctly. So the path then won't work and this is why it is an Invalid argument. The path can simply not be resolved. A fast fix in cmd or ps shell:

wsl --shutdown
wsl

Just restarting the WSL2 worked perfectly for me everytime even though I have appendWindowsPath=false in my wsl.conf file.

All these times I wrote functions to cd into the /mnt/c/ directory and run programs (e.g. code, clip, winget etc), then popd out of it. But for programs which I don't have any control over (e.g. docker-credential-desktop.exe, wslview, wslu etc) writing functions for those seemed little bit too much.

This is a viable workaround till the actual mount problem is fixed.

Remember to follow the WSL 8 Second Rule when restarting.

PS: I did not have any tasks scheduled in my task scheduler.

System information:

Windows 11 22H2
# Output of `wsl -v`
WSL version: 0.58.3.0
Kernel version: 5.10.102.1
WSLg version: 1.0.33
MSRDC version: 1.2.2924
Direct3D version: 1.601.0
Windows version: 10.0.22621.1

[icedream]

I found it's not all Windows commands will have the error, I copied the write.exe, to /var/tmp and ran it, no issue. So only some commands will get the problem, reason is not known.

The problem with that approach is you're copying binaries out of place where they probably have dependencies on other DLLs in the app's directory for example (which is most likely the case for Chrome at least). That can lead to issues with starting up the application early in other ways unrelated to this issue. In this case the application would error out outside of WSL as well anyways.

I would hence consider not using that approach for testing this issue.

[LeDuble]

git

This was a very interesting finding.

It might be that .git is causing this specific issue because I had this problem again today with the following commands code ., explorer.exe . and xdg-open ..

None of these worked, nowhere and it gave an error each time one of them were used.

I did wsl --shutdown and all of these commands worked fine everywhere, except inside the folder which I was working and it had .git file in it.

Have you further investigated this? @sbkpilot1

I will try tomorrow by deleting the folder and cloning it again, just to see if it works then

[Jytesh]

I didn't have this error until I installed Docker Desktop and activated it, wsl --shutdown was able to fix it ( although I am sure it is temporary )

[OMIDBIDBID]

root@OSHAH:/my-app# serve -s build ERROR: Cannot copy to clipboard: Command failed: /root/.nvm/versions/node/v18.4.0/lib/node_modules/serve/node_modules/clipboardy/fallbacks/windows/clipboard_x86_64.exe --copy /root/.nvm/versions/node/v18.4.0/lib/node_modules/serve/node_modules/clipboardy/fallbacks/windows/clipboard_x86_64.exe: Invalid argument

[wzis]

In the post: https://github.com/MicrosoftDocs/WSL/issues/244, JaimeChavarriaga introduced the WSLENV setup: "WSLENV=FORWSL/u:FORWIN/w:GOPATH/l:TMPDIR/p", but I couldn't find a way to change the values of FORWSL, I've tried to modify the /etc/environment, /etc/profile, /etc/login.defs but all could not make FORWSL's values change. Does anyone know how to change it? Thanks in advance.

[ghost]

This looks like something is overwriting your binfmt_misc settings. If these are overwritten by something like mono/wine/other you will see this.

Ignore that thought.

[benyaminl]

For some reason, if I start the WSL using bash or wsl command from cmd, it's gone, the question is why? The problem only exists if I run it from the store distro shortcut in start menu

Why such bug exists in the first place? Can anyone explain what is the different and why that problem exists in first place?

All my Store apps are in C or System Disk, so it shouldn't be the problem in first place. I really curious regarding this problem to be frank.

Thank you. This related to https://github.com/microsoft/WSL/issues/5718#issuecomment-799627980

ping @therealkenc

[RTK3300]

I have the store app as well and just tried in powershell and CMD to run 'wsl', then run 'docker login ' and it still gives me the same error. So doesn't seem to fix it for me.

For some reason, if I start the WSL using bash or wsl command from cmd, it's gone, the question is why? The problem only exists if I run it from the store distro shortcut in start menu

Why such bug exists in the first place? Can anyone explain what is the different and why that problem exists in first place?

All my Store apps are in C or System Disk, so it shouldn't be the problem in first place. I really curious regarding this problem to be frank.

Thank you. This related to #5718 (comment)

ping @therealkenc

[jpeters-vmw]

I had the same issue after doing a reset on my Ubuntu instance. After trying everything in this thread I noticed that I only had the issue when using Windows Terminal app. It would not do it if I launched a remote terminal with VS Code. I had Windows Terminal's Default terminal application setting configured for "Windows Terminal". I changed it to "Let Windows Decide" then launched WSL via the Ubuntu app and tested. It worked as expected. Then I changed the setting back to "Windows Terminal" and the problem stayed away.
I don't know why this fixed it. I spent all day trying everything else in this thread.

[e6c31d]

I can reproduce this issue on Windows 10 and Windows 11 using the below shell script. Note that you need to run this script twice if the first time succeeds for some reason:

#!/bin/sh

cd /mnt/c

dir_to_mount="/mnt/c/dir_to_mount"
rm -rf "$dir_to_mount"
mkdir -p "$dir_to_mount"

cmd.exe /c echo before docker

docker run --rm --mount type=bind,src="$dir_to_mount",dst=/dir_to_mount/ alpine sh -c 'echo inside docker'
rm -rf "$dir_to_mount"

# Uncommenting this fixes the issue
#cd .

# Fails with "Invalid argument"
cmd.exe /c echo after docker

Output:

before docker
inside docker
/mnt/c/WINDOWS/system32/cmd.exe: Invalid argument

My observations:

• The issue happens if docker bind-mounts a directory from a Windows drive. Mounting a WSL directory doesn't trigger it.
• The bind-mounted directly must be freshly created by the script itself. An existing directory (created before the script is run) doesn't trigger it.
• The issue goes away if you cd after running docker. Even a simple cd . fixes it.