NodeJS Error: spawn EACCES (different variants of this error)

[tracy-codes]

Hey all, I've been having this issue for a few weeks now with NodeJS with modules that specifically need to spawn child processes. The two main packages I've enconutered this with are create-react-app's "test" command and Zeit's Now CLI within WSL. Below is the information necessary for the issues I'm experiencing.

Please fill out the below information:

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

• 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.)

Reproduce the Zeit Now CLI Error

1. npm i -g now
2. now login
3. Login with your now credentials
4. git clone https://github.com/tracy-codes/tracycodes-portfolio.git (project files used to push to now)
5. cd tracycodes-portfolio
6. now

Expected output is as follows:

$ now
now
> Deploying ~\dev\tracycodes\tracycodes-portfolio under tracycodes
> Using project my-portfolio
https://my-portfolio-cg6rbcv31.now.sh
┌ **        Ready               [414ms]
├── src/main.js
├── src/img/favicon.png
├── index.html
├── README.md
├── _redirects
├── src/style.css
├── about.html
└── coming-soon.html
> Success! Deployment ready [4s]

Actual output on WSL:

$ now
> Deploying /c/Users/tracy/dev/tracycodes/tracycodes-portfolio under tracycodes
> Using project my-portfolio
> Synced 5 files (8.87KB) [2s]
> https://my-portfolio-8zxgcamfp.now.sh [v2] [1s]
> Error! An unexpected error occurred!
  Error: spawn xsel EACCES
    at Process.ChildProcess._handle.onexit (internal/child_process.js:229:19)
    at onErrorNT (internal/child_process.js:406:16)
    at process._tickCallback (internal/process/next_tick.js:63:19) Error: spawn xsel EACCES
    at Process.ChildProcess._handle.onexit (internal/child_process.js:229:19)
    at onErrorNT (internal/child_process.js:406:16)
    at process._tickCallback (internal/process/next_tick.js:63:19)

Reproduce create-react-app's test error

1. npm i -g create-react-app
2. create-react-app test
3. cd test
4. yarn run test

Expected output:

$ yarn run test
yarn run v1.13.0
$ react-scripts test
No tests found related to files changed since last commit.

Actual output in WSL:

$ yarn run test
yarn run v1.13.0
$ react-scripts test
Determining test suites to run...events.js:173
      throw er; // Unhandled 'error' event
      ^

Error: spawn hg EACCES
    at Process.ChildProcess._handle.onexit (internal/child_process.js:246:19)
    at onErrorNT (internal/child_process.js:421:16)
    at processTicksAndRejections (internal/process/next_tick.js:76:17)
Emitted 'error' event at:
    at Process.ChildProcess._handle.onexit (internal/child_process.js:252:12)
    at onErrorNT (internal/child_process.js:421:16)
    at processTicksAndRejections (internal/process/next_tick.js:76:17)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

• What's wrong / what should be happening instead:
  I'm encountering multiple different "spawn EACCES" errors for Node modules that seem to require spawning child processes.

I've tested this with Jest with --watch, Create-React-App's "test" command, and the Now CLI from Zeit. For Create-React-App's "test" and Jest's --watch, they both output the "Error: spawn hg EACCES" with the above trace. I've tried the following to resolve the issue on my own:

1. Completely remove NPM, Node, and Yarn and reinstall from scratch
2. Install watchman (recommended by FB and seems to fix the issue on some Macs)
3. Set permissions to 777 for global node_modules and local modules in the projects' directories
4. Uninstalled/Deleted WSL and did a clean install, installed Node/NPM/Yarn first, then went through the reproduction steps above and still encountered the errors

Please let me know if there's anything else I can provide to add value to this issue report, and I hope someone can help me find a resolution for this!

I've reported this issue to Zeit's Now CLI team and they haven't ever encountered this error before:
#1902

[craigloewen-msft]

Hi @tracy-codes !

Could you please run an strace on the failing commands? Instructions on how to do so are here.

It'll help us get a better picture of what's going on!

[tracy-codes]

Hi @tracy-codes !

Could you please run an strace on the failing commands? Instructions on how to do so are here.

It'll help us get a better picture of what's going on!

Hi @mscraigloewen! Thank you so much for taking the time to investigate this issue. The following two gists are for the Now and the create-react-app test straces:

1. Now Strace Output
2. create-react-app test strace output files (this generated 198 strace files, these are the ones >1000kb):
   • https://gist.github.com/tracy-codes/cdec11a0410b264f55dacb8b0b649801
   • https://gist.github.com/tracy-codes/2952a3f58dda62a3c1ecc60bf6442596\
   • https://gist.github.com/tracy-codes/909062c6481d356f0f0a290863b7f6a7
   • https://gist.github.com/tracy-codes/f388c023607a53f663611f02532b7954
   • https://gist.github.com/tracy-codes/cca19eb84d6569eefdaeb740b71d3926

[craigloewen-msft]

No problem :) We'll take a look and post any updates as they become available.

[tracy-codes]

@mscraigloewen Sounds good! Thank you ❤

[therealkenc]

Well, the only EACCES in there is:

execve("/c/Users/Administrator/AppData/Local/Microsoft/WindowsApps/xsel", ["xsel", "--clipboard", "--input"], 0x4286910 /* 30 vars */) = -1 EACCES (Permission denied)

Which would strangely enough make this variation #3833 (comment).

What does echo $PATH return for you right before you run now? Try:

$ export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ # ... do node things

That might still fail for other reasons if now really requires xsel(1). It might not. (Wouldn't know. There is no repro and I've never really been a huge Tangerine Dream fan.)

If now really does require xsel(1) for reasons, then do sudo apt install xsel after rationalizing your $PATH.

[tracy-codes]

@therealkenc Running that path cmd and doing my node things seems to have worked! I think this issue is solved by the export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin command. Thank you so much!

[craigloewen-msft]

I'll close out this issue. Thank you for the fix @therealkenc , and thanks for filing the issue @tracy-codes !

[therealkenc]

Thank you for the fix @therealkenc

YW. Glad you're up and running.

But just for clarification, the underlying bug in both this issue and #3833 remains. I have no horse in that race mind you, and am never one to turn down a closed issue#.

If /c/Users/Administrator/AppData/Local/Microsoft/WindowsApps/xsel or /mnt/c/WINDOWS/system32/config/systemprofile/.dnx/bin/help can't be executed, then they shouldn't have been marked as executable. This is a diverge. I can't tell for sure if that counts as dupe #2779 or not (maybe not). But I can say the WSL ABI is coughing up dirents that claim they can be executed when they can't. Because, otherwise now wouldn't have tried to execve() the thing, only to die trying. Rationalizing the $PATH to something sane avoids the issue, but doesn't address the underlying problem. Just sayin'.

[craigloewen-msft]

Ah I see! I'll re-open the issue so we can track that the underlying cause isn't fixed.

[therealkenc]

Alright I looked a little closer since I went and opened my mouth. I had said quoth "the WSL ABI is coughing up dirents that claim they can be executed when they can't". That isn't the case. zsh and presumably now (whatever now is) is blindly appending names to the $PATH components. This makes sense in Real Linux™ because putting a component in your $PATH that you don't have permission to access is just plain "user error".

In WSL (contrast the real thing) we have the added snag of paths where the underlying Windows user doesn't have permission. This is harmless in Windows because Windows software is written with the assumption that can happen. Having nonsensical components in one's Window's %PATH% is "normal". But Linux software isn't written with that assumption.

The repro over in #3833 is maybe better because .../Microsoft/WindowsApps/xsel here looks to be something third party that the OP installed. Over there, .../.dnx/bin is in WSL's $PATH if you've installed Visual Studio 2015. [I gather. Actually I wouldn't know a DNX from the hole in the ground either but I think it gets put in the Windows %PATH% along with the kitchen sink that is MSVS.] I guess I got "lucky" because if I didn't have MSVS 2015 I wouldn't have had the path component, I wouldn't have been able to reproduce #3833's problem either.

$ echo "$PATH" | tr ':' '\n' | grep WINDOWS/system32
/mnt/c/WINDOWS/system32
/mnt/c/WINDOWS/system32/config/systemprofile/.dnx/bin

But that path isn't accessible, because the Windows user (me) doesn't have permissions to that path. That's going to be the case for the OP's xsel too.

Fix is going to be to launder path components from being imported when the Windows user doesn't have permission to that component. Basically, interop is imposing a "user error" on WSL, because it is putting components in the $PATH that can't ever be accessed. The ABI strictly speaking is correct.

[samtstern]

Running into this issue when trying to child_process.spawn() a java command but the user doesn't have Java installed. So as I understand the above it's trying to check everything in the $PATH but then runs into permissions issues?

[therealkenc]

Yes

[jottasystem]

some problem ...

[Konfekt]

Among all those converted paths in %PATH% appended to $PATH some contain subdirectories named like common executables, say help or md5. (As an aside, perhaps they should preferably be prepended?)

For the moment, you can remove in ZSH an offending path that contains a subdirectory named like an executable, say /mnt/c/Program Files (x86)/Lua/5.1/clibs which contains a subfolder md5, from $PATH by

# See https://stackoverflow.com/questions/370047/what-is-the-most-elegant-way-to-remove-a-path-from-the-path-variable-in-bash/29159378#29159378
removeFromPath() {
   local p d
   p=":$1:"
   d=":$PATH:"
   d=${d//$p/:}
   d=${d/#:/}
   PATH=${d/%:/}
}
removeDirFromPath "/mnt/c/Program Files (x86)/Lua/5.1/clibs"

See this question for possibly further answers.

[Konfekt]

According to these comments the fix might be as simple as updating zsh to version 5.7.1.

[fgarcia]

My personal fix to avoid this problem was the realization that in WSL:

mv file.txt other.txt

fails miserably when there are file watchers, but

cp file.txt other.txt
rm file.txt

is totally OK

😔

I am trying to survive with a temporal shell alias mv.wsl until WSL2 solves all the problems ✨

[saulwiggin]

I'm still having this error when I try to spawn a process on node. Is it to do with file permissions?

[Konfekt]

According to #3886 (comment) if the fix

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

works for you, too, then this issue is probably due to an executable in the environment variable %PATH% of Windows, converted and appended to $PATH of Linux, clobbering the intended executable in $PATH. To boot, there is seemingly a bug in ZSH < 5.7 that adds even subdirectories (whose executable flag is set) in a directory in $PATH to those executables.

[therealkenc]

converted and appended to $PATH of Linux, clobbering the intended executable in $PATH.

No intended executable is (quoth) "clobbered". The intended executable doesn't exist, except on Windows, so the Windows exe gets picked up in the path walk. Subsequently, people launder their path per suggestion, discover the missing executable (commonly npm), install it, and their node workflow starts working. But it doesn't have to be npm. It can be any executable in the node ecosystem that gets spawned by a node script.

To boot, there is seemingly a bug in ZSH < 5.7 that adds even subdirectories (whose executable flag is set)

If you're referring to the zsh behavior here, that can be problematic, yes. If the behavior has changed in zsh a PR reference would probably be handy. Otherwise by-design zsh (for some version of zsh).

There is also #4104, and an edge case that occurs more often than you'd expect: a component in the user's Windows %PATH% which the user doesn't have permission to access; in this case xsel. That might, or might not, be recently addressed #2779.

In any event, the OP was unblocked and there is no novel actionable remaining on this one (or, technically, a repro). Someone super motivated could in principle open a new issue with specific CLI repro steps (including the steps necessary to get the Windows %PATH% in a particular state) in the hypothetical there still remains a novel issue outstanding. [Noting, this is always possible but statistically unlikely.] Thanks everyone for the feedback.