"Access is denied." when running as LocalSystem

[TapeWerm]

• Your Windows build number: (Type ver at a Windows Command Prompt) Microsoft Windows [Version 10.0.18363.535]

• 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.) I was trying to use WinSW to make a Windows service for a Bash script and got "Access is Denied." Then I tried to make a Windows service calling bash.exe -c script.sh in Visual Studio and the script did not run. Then I opened a shell as LocalSystem and yet again got the error "Access is Denied." To open a shell as LocalSystem, do the following:

Download Sysinternals PsExec64.exe

.\PsExec64.exe -i -s cmd.exe
bash.exe
wsl.exe

Access is denied. 🎊

• What's wrong / what should be happening instead: I assume it's supposed to prompt you to setup WSL as LocalSystem. I know my personal user's rootfs is in my %appdata%, so I assume LocalSystem would have to go through the setup. Perhaps LocalSystem needs a distro from the Microsoft Store. Maybe WSL is not meant to be used like this. To be fair, I am not sure what the intended behavior is.

• Strace of the failing command, if applicable: (If some_command is failing, then run strace -o some_command.strace -f some_command some_args, and link the contents of some_command.strace in a gist here).

• For WSL launch issues, please collect detailed logs.

[TapeWerm]

logs.zip

[valeriob]

Hi, i'm having the same issue, running as local system account results in access denied. Did you find any solution ?

[TapeWerm]

I never found any solution.

[valeriob]

I'm trying with LOCAL SERVICE but i get the error "W i n d o w s S u b s y s t e m f o r L i n u x h a s n o i n s t a l l e d d i s t r i b u t i o n s . " instead, i guess that wsl is installed for a single users.

[valp124]

Same exact issue, which prevents me from using bash in Azure DevOps pipelines. How can there be no response to this whatsoever in all this time??

[valp124]

I found a workaround, by the way, for anyone interested. After much tinkering, I managed to take ownership of C:\Windows\System32\bash.exe and that allowed me to rename it (I didn't want to delete). After that, I created a symbolic link:

mklink bash.exe "c:\Program Files\Git\bin\bash.exe"

It's a poor man's bash, but at least it works, I tested it with psexec and through the Azure pipeline.

[luckerby]

@valp124 I'm running into the same exact problem, particularly since I need the Azure DevOps self-hosted agent to run as LOCAL SYSTEM.

However I still get "Access denied" running as LOCAL SYSTEM (via psexec -s -i cmd.exe) even after moving bash.exe and creating the symlink. Is there some additional step to be done?

[valp124]

@luckerby, when you test via psexec, are you running the command as admin? Be sure to run whatever shell you're using "As Administrator." Other than that, I wouldn't know what to say, it still works for me. (You'd think that a Windows update would break it at some point.)

[valp124]

You can see below that the linked bash works, but the original bash and wsl don't.

However:

[luckerby]

@valp124 Thank you for your quick reply! I've somehow missed the obvious, whereby the symlink has to point to an actual bash client (e.g. Git's built-in one). For some weird reason, I moved the original bash.exe and created a symlink to this one (I know, doesn't make any sense, particularly since your explicit mklink command made it clear what the end goal was; I also have a hunch that SYSTEM32's bash.exe is just a stub and expects to find a real bash client in the Linux distro installed).

So just to confirm, @valp124's solution still works perfectly with Azure DevOps, particularly when you need to run the self-hosted agent as LOCAL SYSTEM.

I did found another workaround for running the Azure DevOps self-hosted agent under a different account than the default NETWORK SERVICE, and tested this successfully on WSL1. Simply create another local user on the Azure DevOps self-hosted agent, add it to the local Administrators group, install a Linux distro by running the distribution launcher app (full procedure is here) and then configure the agent service to run as that particular user.

Unfortunately this doesn't work for the initial issue of this thread: trying to install a Linux distro while running as LOCAL SYSTEM (e.g. in the interactive window opened by psexec -s -i cmd) by using the distribution launcher app (full procedure is here) will fail with: WslRegisterDistribution failed with error: 0x80070005. Error: 0x80070005 Access is denied. Which brought me back to the same thought @TapeWerm had in the initial post, that maybe WSL is not meant to be used this way.

As a side note, using ProcMon to identify the cause of the "Access is denied" didn't lead me anywhere: all I can see what several threads created by bash.exe and then almost immediately terminated, but no operation that would result in an access denied status message.

[valp124]

Right, @luckerby, I figured changing the user under which az agent runs would work, but in my case, messing with the Admin group is not an option, any changes are overwritten by the corporate policy after a short while.

@therealkenc, it would seem to me that this needs to be addressed.

[valp124]

It's not ok to close an unresolved issue.

[rbability]

I can confirm that this is still an issue, just ran into this yesterday. It makes it difficult to use when utilized by Azure DevOps or GitHub Self-Hosted runners which run with LocalSystem permissions by default and are not meant to have more permissions in the system.

[pa-0]

Was this issue addressed elsewhere? I see it's closed but I don't see any response.

[valp124]

I am opening a new issue on the same subject.