chrome-launcher: Fails to create tmp directory on WSL

Provide the steps to reproduce

Run LH inside WSL2

What is the current behavior?

Runtime error encountered: EACCES: permission denied, mkdir '/mnt/undefined'
Error: EACCES: permission denied, mkdir '/mnt/undefined'
    at Object.mkdirSync (fs.js:750:3)
    at sync (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/mkdirp/index.js:71:13)
    at sync (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/mkdirp/index.js:77:24)
    at sync (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/mkdirp/index.js:77:24)
    at sync (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/mkdirp/index.js:77:24)
    at sync (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/mkdirp/index.js:77:24)
    at Function.sync (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/mkdirp/index.js:77:24)
    at makeWin32TmpDir (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/chrome-launcher/dist/utils.js:115:12)
    at Object.makeTmpDir (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/chrome-launcher/dist/utils.js:85:20)
    at Launcher.makeTmpDir (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/chrome-launcher/dist/chrome-launcher.js:115:24)

What is the expected behavior?

No error.

Environment Information

Affected Channels: CLI
Lighthouse version: 5.6.0
Chrome version:
Node.js version: 10.14.1
Operating System: Ubuntu on Windows 10 WSL2

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 24 (8 by maintainers)

Most upvoted comments

I am also having a problem with lighthouse inside WSL2.

It opens the chrome browser but then hangs with:

It looks like lighthouse succeeds to open chrome but cant seem to connect and manage it

michaelchiche on Feb 6, 2020

the 6.0 release was just cut yesterday

🥳 you just made my day, as that will hopefully let us address the audit reports (I’ve not checked it out locally to run auditing against it, but seen PRs updating the dependencies that are being reported, so fingers crossed).

The beta is using 0.13.x - I remember seeing the PR; I’ll check it today if I have the time but otherwise use v6 on Monday 🥳🎉

G-Rath on May 15, 2020

SGTM @G-Rath thanks for your help! We should avoid any string interpolation from string commands though, opting for execFile and passing as arguments instead. (#199 mistakenly believes we do this already but we certainly shouldn’t start 😄)

FWIW there shouldn’t be any sequencing issues with Lighthouse dependency here, publishing a fix should be enough for new installs and folks to be able to update their lockfiles since it uses a loose ^0.13.2 dependency.

patrickhulce on May 14, 2020

It’s pretty common nowadays to configure WSL not to append the Windows PATH to the Linux PATH because it slows everything down SO MUCH

I don’t know about that, but in my case I get this issue because I have my C:\ mounts in /c/ instead of /mnt/c/, which is required due a bug in docker.

Ultimately the most stable fix is probably to call wslpath "C:\" at the top level once you know it’s WSL.

G-Rath on Apr 6, 2020

Ah great find @villasv! No need to copy we can transfer the issue over 😃

patrickhulce on Feb 4, 2020

Looking at the code you highlighted, I think it’s something else. I don’t have my Windows PATH appended, so very likely process.env.TEMP = getLocalAppDataPath(`${process.env.PATH}`); is yielding TEMP = undefined.

It’s pretty common nowadays to configure WSL not to append the Windows PATH to the Linux PATH because it slows everything down SO MUCH. My suggestion is to rely on the usual linux tooling for tmp directories.

Should I close this and copy the bug report on chrome-launcher?

villasv on Feb 4, 2020