Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

"EACCES: permission denied" if additional executable with same name appears on PATH when using @actions/exec #1925

Open
Vampire opened this issue Jan 3, 2025 · 1 comment · May be fixed by #1953
Open

"EACCES: permission denied" if additional executable with same name appears on PATH when using @actions/exec #1925

Vampire opened this issue Jan 3, 2025 · 1 comment · May be fixed by #1953
Labels
bug Something isn't working

Comments

@Vampire
Copy link

Vampire commented Jan 3, 2025

I use @actions/exec in my setup-wsl GitHub Actions action to do various tool runs.

One of the tools that is run is wsl.
To use WSLv2 on windows-2022 currently, you have to do a wsl --update first.
To use any version of WSLv2 on windows-2025 currently, you have to do a wsl --install --no-distribution first.

Both of these commands add an addtional wsl.exe link to C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps - which is on the PATH - that was not there before.

If you now use exec() to run a wsl command, you always get

Unexpected error attempting to determine if executable file exists 'C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps\wsl.EXE': Error: EACCES: permission denied, stat 'C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps\wsl.EXE'

spamming the build output.

To reproduce, first do a wsl --update through exec(), then a wsl --status through exec() on a windows-2022 image that does not yet have actions/runner-images#10563 done.
@Vampire Vampire added the bug Something isn't working label Jan 3, 2025
@ssbarnea
Copy link

ssbarnea commented Feb 13, 2025 •
edited
Loading 

>where wsl
C:\Users\runner\AppData\Local\Microsoft\WindowsApps\wsl.exe
C:\Windows\System32\wsl.exe

First one is a symlink, second one is an executable. It is a bit confusing to see an error with the uppercase extension (as most FS outside Windows world are case-sensitive).

I suspect that we could remove the symlink as both locations are in PATH to avoid the error, but I still think that the error should not happen because Windows does allow execution of the symlink without any problems, so the stat check is broken, it should pass.

I raised #1953 which should fix the issue but considering that nobody looked at the issue so far and that they don't even run the CI w/o approval,... it might take a lot of time to get someone attention.

With a bit of luck maybe @thboop, @luketomlinson or @Link- might see #1953 and review it.

ssbarnea added a commit to ssbarnea/toolkit that referenced this issue Feb 13, 2025
@ssbarnea
Recognize symlinks
b2444c0 
Fixes: actions#1925
@ssbarnea ssbarnea linked a pull request Feb 13, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Make @actions/exec correctly recognize symlinks in path ssbarnea/toolkit
2 participants
@ssbarnea @Vampire