"Invalid argument" when executing Windows commands on Ubuntu 20.04 #6170
Comments
|
Are you with ARM device? |
|
No, it's a x64 |
|
Hello, I see no answers. |
|
@gAllegr I have the same problem. Did you figure out a solution? |
Unfortunately no |
|
I am facing the same problem. Wondering why was this issue closed. The issue linked to above was also not resolved. |
|
I am facing the same problem. after run docker login |
|
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.
|
|
I am encountering the identical problem
Windows version: 10.0.21337 Build 21337 |
|
This appears to be the same issue as #4260 |
|
I find a work arround for now using bash/ash shell, by mounting the folder as disk drive see #5718 (comment) to mount the network location as drive (on insider should be wsl.local) You can create file on #!/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 "$@"
fifor 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 "$@"
fifor 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 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 I can did this because strangely it works on /mnt/c/ directory, at least the windows exe work on windows partition. |
|
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.) 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! |
|
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. |
|
I have the same issue, but I have verified that it only happens when my 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 argumentAs a workaround, make a shell script called #!/usr/bin/bash
curdir=$PWD
cd /
cat | clip.exe
cd $curdirNow you can just do $ echo test | clip |
|
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):
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. |
|
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 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 |
|
Interestingly WSL is in this state almost everytime I start my computer. If I do a |
|
Add VSCode to the path this solved to me. |
|
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 |
|
This has something to do with 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. |
|
It's definitely have something to do with path. Here is an easy reproducible workaround:
Inside WT: 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 |
|
I'm faced with the same problem of getting And then there's also the issue with not being able to access the network drive under |
|
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 (!). |
|
I see this pop up seemingly randomly. Doing a |
|
I created a simple script and added a symlink to replace the normal #!/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) |
|
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. |
|
I tried to copy the chrome.exe from the Windows "Program Files" directory to /var/tmp/, then run it , got the same issue, why: |
|
This might helps someone else here. I just got this issue this morning. Not sure what changed, everything was working fine yesterday. Last night I hibernated. This morning I noticed that WSL started up faster than usual, which surprised me as it usually takes a minute. Then I do my usual And I get that Then, I closed WSL session and from Powershell, I did Restarted WSL and now Code is working again! |
|
I use wezterm had to set |
|
@OneBlue or @craigloewen-msft Hello, any news/updates on this issue? Several users have reported this issue going back almost 3 years now, but there have been no fixes, or acknowledgements even. |
|
The I've not tracked down what causes the "Invalid argument" to start happening - I used to think it was sleeping/hibernating that was the issue, but I've observed it happening even without sleep. It happens at least once a day. This issue and #4698 are both major barriers preventing me from recommending WSL2 to anyone as a daily driver for work. |
|
So at least for me, I have found the Invalid argument behavior was caused by the WSL_DISTRO_NAME environment variable in Linux not matching my distro name from "wsl --list", note this behavior is easily reproducible: (~)[513]> set |grep WSL (~)[514]> net.exe NET (~)[515]> export WSL_DISTRO_NAME=not_the_right_name (~)[516]> net.exe (~)[517]> export WSL_DISTRO_NAME=Ubuntu-22.04 (~)[518]> net.exe NET |
|
Same problem here, but WSL_DISTRO_NAME matched the wsl --list distro name. Only workaround I've found is to terminate and relaunch wsl. |
|
I encountered similar issue while I was trying to run .exe file from systemd. It turned out my bash has an env var the systemd service doesn't have: export WSL_INTEROP=/run/WSL/342519_interopIf this env var is missing, you'll see an |
|
This is the exact same output you get if applocker blocked the binary exe, just a heads up. |
|
@OneBlue We are using WSL to run a Linux GitHub runner under Windows, while using the Windows executable of the Git credential manager to obtain the Git token from WSL. In the GitHub workflow running in Ubuntu/WSL, a Git clone randomly fails with When I trace the As 0x8007010B translates to The directory name is invalid, it seems like the code that launches the Windows executable fails to provide the proper directory, or perhaps uses the current directory of the process or the WSL path that cannot be translated to a DOS path? That may be the reason why the issue occurs at random. |
|
As a sidenote, if the Windows error is indeed The directory name is invalid, the errno mapping could be improved. |
Thank you @eur2fe. Can you post the full logs ? /logs |
|
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: 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! |
|
I had to implement a workaround to keep our GitHub runners working, so I cannot reproduce this specific problem. However, I created a small repro that may help. Essentially it triggers a race that causes the process creation to fail due to an invalid current directory. Not sure if the root cause is the same (here the current directory being non-existent), but the outcome is the same. I have also seen the problem that the original post is referring to, where I am in the users home directory and the Windows process creation fails consistently (which sounds more like a communication problem with the VM). I am sending you the logs via e-mail. #include <stdio.h>
#include <errno.h>
#include <unistd.h>
#include <sys/stat.h>
int main(int argc, char **argv)
{
int result;
const char* home = "/home/user";
const char* path = "/home/user/test";
result = mkdir(path, 0755);
printf("mkdir: %d\n", result);
result = chdir(path);
printf("chdir: %d\n", result);
FILE* file = popen("/mnt/c/Windows/system32/cmd.exe /c echo Hello", "w");
usleep(10000);
result = chdir(home);
printf("chdir: %d\n", result);
result = rmdir(path);
printf("rmdir: %d\n", result);
result = pclose(file);
printf("pclose: %d\n", result);
return 0;
}user@host:~$ cc test.c && ./a.out
mkdir: 0
chdir: 0
chdir: 0
rmdir: 0
/mnt/c/Windows/system32/cmd.exe: Invalid argument
pclose: 256If I make the usleep delay sufficiently large, it works: user@host:~$ cc test.c && ./a.out
mkdir: 0
chdir: 0
'\\wsl.localhost\Ubuntu-22.04\home\user\test'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
Hello
chdir: 0
rmdir: 0
pclose: 0 |
|
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! |
|
Same issue with git commands. |
|
The above release doesn't appear to have fixed the issue for me. I'm on WSL Release 2.1.0 (in a windows terminal): but from inside Ubuntu on WSL from my home directory: For me, WSL may work for a few hours without this problem, but at some point it appears. Once it starts, every |
|
+1, I believe this issue is not resolved. FWIW, a wsl --uninstall and re-install solved it for the same version. Its possible that the container was created with an older version and hence the problem randomly manifested |
|
I get this if I'm inside a directory mounted with rclone. cd ~
echo 'hi' | clip.exe # works
rclone mount sharepoint: ~/sharepoint --vfs-cache-mode full --max-read-ahead 1024Ki --daemon
cd ~/sharepoint
echo 'hi' | clip.exe # error: /mnt/c/Windows/System32/clip.exe: Invalid argument
|
Same for Samba mounted folder. (was trying to use it as a workaround for drvfs problems) |
|
I encountered this today on:
|
|
Same here. Happens randomly during my working day.
|
and others
Environment
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.execommand (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 argumentNote: I searched in previous issues for some help on how to solve this, but didn't found how to
The text was updated successfully, but these errors were encountered: