yarn install error ENOENT: no such file or directory

[johnvuko]

Yarn version: 1.1.0
Node version: 6.9.4
Platform: linux arm Raspbian 64 bits (Raspberry pi 3)

When I run the command yarn install --production with a yarn.lock file I have a random error

 Error: https://registry.yarnpkg.com/postcss-merge-idents/-/postcss-merge-idents-2.1.7.tgz: ENOENT: no such file or directory, open '/home/pi/.cache/yarn/v1/npm-postcss-merge-idents-2.1.7-4c5530313c08e1d5b3bbf3d2bbc747e278eea270/README.md'

Not always on the same package, it's look like an old bug: #2629

I manage to complete the installation with the command with yarn install --production --network-concurrency 1.

I try to clear the cache but the problem was still present.
The problem may be related to very bad network connection, the installation stopped not much after seeing a warning about a failed connection.

yarn-error-viktor.log
yarn.lock.txt

[matthewtoast]

Hopefully not noise: I see a similar symptom on 1.0.2, and I wonder if it could be the same cause:

error An unexpected error occurred: "ENOENT: no such file or directory, scandir '/path/to/node_modules/something'"

• I've seen this fail on calls to scandir, lstat, as well as open.
• Same as OP, it often occurs on a different package each time.
• If I run the same command over and over, eventually it succeeds.
• The project in question has several yarn link'd modules.
• I see this error occur intermittently when I run any of the following variations:

$ yarn install --mutex file:/tmp/.yarn-mutex
$ yarn install --mutex file:/tmp/.yarn-mutex --network-concurrency 1
$ yarn install --network-concurrency 1
$ yarn upgrade some-dep --mutex file:/tmp/.yarn-mutex
$ yarn upgrade some-dep --mutex file:/tmp/.yarn-mutex --network-concurrency 1
$ yarn upgrade some-dep --network-concurrency 1

My system specs:

Yarn version: 1.0.2
Node version: 8.4.0
Platform: macOS Sierra (10.12.4)

[ChristianG1984]

My installed yarn version: 1.2.1
OS Version: Windows 10 (Latest Fall Creators Update)

I have often a similar problem, when I try to use the command electron-forge init --template=angular2. electron-forge uses yarn internally, when it is installed.
It feels to me, if there is something like a race condition or the like. Sometimes, there are no errors at all. And another time, I get very much errors of that kind after several trials.
I wrote a detailed error report there: electron/forge#356

[aindlq]

I can confirm exactly the same behaviour as reported by @matthewtoast. We are having this issue for the last 3 months. The interesting thing is that it always happens on our CI (jenkins in docker, official image) and on machines with macOS, but it never happend to me on archlinux.

Yarn version: 1.2.1
Node Version: 8.9.0

[mscharley]

Also having issues with this when running yarn inside Docker. I haven't seen it outside Docker, but I don't use it much outside Docker either.

Yarn version: 1.2.1
Node version: 6.10.3
Host machine: OSX 10.12.6
Docker version: 17.09.0-ce-mac35

[jure]

Same thing is happening here, sometimes it passes, sometimes it doesn't. It's not connected to any mutex configuration, as it happens with all.

Yarn 1.3.2
Node: 8.8.1
OS X 10.12.6

[edoshor]

For me it was a disk space issue. I was running out of inodes (df -i).
Once settled, yarn --prod was successful.

[kingjerod]

Getting this error a lot with random missing files in Docker node:9 image. Not sure if it has something to do with docker-compose mounting the files from host? This makes yarn un-usable as I can't install anything, it all results in the same error. Only "fix" I've found is deleting the entire node modules folder and re-installing. This only seems to work for a bit.

Error: ENOENT: no such file or directory, copyfile '/usr/local/share/.cache/yarn/v1/npm-ansi-bgwhite-0.1.1-6504651377a58a6ececd0331994e480258e11ba8/package.json' -> '/app/node_modules/ansi-bgwhite/package.json'

Arguments:  /usr/local/bin/node /opt/yarn-v1.5.1/bin/yarn.js install

PATH:  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Yarn version: 1.5.1
Node version: 9.10.1
Platform: linux x64

[garytryan]

Getting the same error consistently.

Arguments: 
  /usr/local/Cellar/node/8.9.1/bin/node /usr/local/Cellar/yarn/1.6.0/libexec/bin/yarn.js

PATH: 
  /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/lib/node_modules/.bin:/usr/local/lib/node_modules/.bin

Yarn version: 
  1.6.0

Node version: 
  8.9.1

Platform: 
  darwin x64

Trace: 
  Error: ENOENT: no such file or directory, lstat '/Users/gary/Documents/code/build/packages/api-core/node_modules/envkey'

[RealAdamSinger]

I have started experiencing this issue as well. I've tried different fixes but it just seems to vary to which file is the issue.
It may be of note that I am running bash on ubuntu with windows 10

i'm on yarn 1.5.1 will try updating now

update: problem persists

[mike-marcacci]

I see this running v1.7.0 on MacOS. This was occurring consistently in a large project that uses yarn workspaces with liberal nohoist patterns, but hadn't happened in small, simple projects on the same machine.

yarn-error.log

Arguments: 
  /usr/local/bin/node /usr/local/Cellar/yarn/1.7.0/libexec/bin/yarn.js install --network-concurrency 1

PATH: 
  /Users/mike/Applications/google-cloud-sdk/bin:/Users/mike/.cargo/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin

Yarn version: 
  1.7.0

Node version: 
  10.7.0

Platform: 
  darwin x64

Trace: 
  Error: ENOTDIR: not a directory, lstat '/Users/mike/Code/boltline/app/packages/boltline-native/node_modules/@boltline/grades/node_modules/expand-brackets/node_modules/debug/.eslintrc'

npm manifest: 
  {
    "private": true,
    "license": "UNLICENSED",
    "author": "Mike Marcacci <[email protected]>",
    "scripts": {
      "lint": "flow && eslint .",
      "precommit": "lint-staged",
      "prettier": "prettier \"packages/*/src/**/*.{js,css,.md}\" --write",
      "deploy": "scripts/deploy.sh",
      "dev": "scripts/dev.sh"
    },
    "repository": {
      "url": "https://github.com/boltline/app.git",
      "type": "git"
    },
    "workspaces": {
      "packages": [
        "packages/core",
        "packages/grades",
        "packages/boltline-native",
        "packages/boltline-web"
      ],
      "nohoist": [
        "**/**",
        "**/@boltline/core",
        "**/react-native",
        "**/react-native/**",
        "**/@mapbox/react-native-mapbox-gl",
        "**/@mapbox/react-native-mapbox-gl/**",
        "**/react-native-*",
        "**/react-native-*/**",
        "**/vm-browserify",
        "**/vm-browserify/**"
      ]
    },
    "devDependencies": {
      "husky": "^0.14.3"
    },
    "dependencies": {}
  }

yarn manifest: 
  No manifest

Lockfile: 
  No lockfile

I tried many different tricks (clearing cache, limiting network concurrency, etc) but what finally succeeded was making sure @boltline/grades was declared as a dependency in all its sibling packages. This may just be coincidence, but also might suggest a starting point for someone more familiar w/ yarn internals.

[alexmcmillan]

Windows 10
Node 8.11.1
NPM 5.6.0
yarn 1.9.4

Running on bash (via WSL) inside VSCode.

Running yarn install succeeds through "Resolving Packages...", "Fetching packages..." then fails on "Linking dependencies..." references ENOENT with either lstat or scandir. The file referenced changes every time, and does not exist.

Further investigation shows that the "Fetching packages..." stage doesn't actually fetch anything. It creates the entire directory tree under /node_modules/, but doesn't download a single file. It also completes lightning fast, and doesn't produce any error/warning.

Running sudo yarn install works.

This is likely related to WSL and filesystem permissions more than yarn, but it would be nice if yarn produced some kind of error/warning message at "Fetching packages..." when it actually fails to do so.

[domis4]

for fellow googlers having the same problem: its a file system restriction.

Windows 10, Ubuntu Bash & yarn when even sudo yarn install does not work, while highly discouraged doing so, will probably fix it:

sudo chown -R domi:domi /usr/local/
sudo yarn install --network-timeout 10000000

warning: your node modules will be installed with root rights which is a potential security risk. This however fixes days not beeing able to install any yarn package

[mike-marcacci]

This is unfathomably frustrating, especially when running yarn upgrade-interactive --latest with yarn workspaces, since failure clears out your version selections. Over the last few months, this has cost days of trial and inevitable error, and if we hadn't invested in yarn workspaces, we would just use NPM.

My strategy now is to run it in a loop until it succeeds. Here's for other sorry souls who are at their wit's end and just want the damn packages installed:

until yarn; do; echo "Surprise, surprise. Let's try again..."; done

Run that, set your laptop away from anything flammable, and go get dinner. Best luck.

[AhtiAhde]

I actually believe I might have a hypothesis of the issue here.

How many of you use watcher processes, such as auto-build, hot reload or automated localhost servers defined at scripts section of the package.json file? When I turn these off, I do not have to use sudo or other tricks. This might be related to the fact that system user has much more file I/O privileges than regular users and many JS packages do have thousands of files; so if your watchers triple that amount of file I/O, then you might just meet the cap of 8000 files.

I didn't have this issue at older machine, when I had increased the file cap due to building really fast web scraper, which used temp/shm as storage.

[kennethlynne]

I'm having this issue now.

Even retrying many times does not solve it. I thought I would give yarn a go to use the workspaces feature.
Now I'm worried I made the wrong choice, finding several old unresolved issues like this one about this weird issue 😅

[kennethlynne]

Solving this temporarily with yarn install || yarn install || yarn install to try three times, and migrating everything to use lerna and npm instead. No idea how to attack this without spending more valuable time since the logs are so lacking of any information

I've tried sudo yarn install, I've tried older versions of yarn I've tried doing it in docker, I've tried configuring max concurrency etc. Nothing solves it so far.

[tombh]

I was getting this same frustrating and hard to debug error. The problem in my case seemed to be yarn workspace behaviour caused by different versions of the same dependency in different packages (specifically ava versions 2 and 3). Only once I'd upgraded all occurrences of ava to their latest did I stop getting this error.

[GoMino]

I can confirm I have the same issue with yarn workspace, when extensively using no-hoist

[desfero]

Can also confirm the issue started to appear after different version of the same dependency is used across the monorepo.

[BlueRaja]

We also have "a large repo using workspaces and no-hoist". I see this issue 100% of the time when using any of

• yarn upgrade
• yarn upgrade-interactive
• yarn add

But I can run yarn install just fine. Running yarn v1.22.4

[kiptoomm]

I have observed a very similar issue when trying to install a package with local path using yarn add file:./my-config:

error An unexpected error occurred: "ENOENT: no such file or directory, scandir '/Users/me/Library/Caches/Yarn/v6/npm-tw-config-1.0.0-7015ab00-060c-4b4e-8b2e-388d8934c404-1599154091934/node_modules/my_config'".
info If you think this is a bug, please open a bug report with the information provided in "/Users/me/my-project/functions/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

The install command only seems to work when the relevant local path in package.json matches ../my-config (./my-config is actually a symlink to ../my-config, and yet this same exact line works when using npm):

"dependencies": {
    "my_config": "file:../my-config"
 }

[ghost]

I was getting this same frustrating and hard to debug error. The problem in my case seemed to be yarn workspace behaviour caused by different versions of the same dependency in different packages (specifically ava versions 2 and 3). Only once I'd upgraded all occurrences of ava to their latest did I stop getting this error.

I'm noticing this issue with a repo where the packages can't be deduplicated to a single major version. So that makes it kind of hard to resolve this issue. Is there any feedback from the yarn team on this issue? It's been open for over three years.

[Npervic]

Any one have any idea why is this happening its tbh its infuriating.

[merceyz]

Closing as fixed in v2 where the cache has been improved to avoid these sorts of issues

https://yarnpkg.com/getting-started/migration

[christianchownsan]

I experienced this issue with I a yarn v1 monorepo which had aggressively no-hoisted packages, when I tried to create dependent references between the packages. My workaround was to

• use the file:... form of dependencies rather than via semver
• used yarn link as a postinstall step to switch out the hoisted (copied) directory for a symlink (cd sharedlib && yarn link && cd ../uses-sharedlib && yarn link sharedlib)

ps @merceyz is there no better way of managing yarn v1 issues than just closing them because they're fixed in v2?

[merceyz]

ps @merceyz is there no better way of managing yarn v1 issues than just closing them because they're fixed in v2?

That's sort of the whole point of issues, no? Close them as they get fixed

[jakerobb]

That's sort of the whole point of issues, no? Close them as they get fixed

Not when the upgrade is a complete-rewrite new major version with a migration path preventing some users from upgrading immediately, and you're still supporting the old version with patches. Maybe prefix the issue title with [v1] or add a label or something, but don't close it until you stop supporting V1.

(Apologies if you've already stopped supporting v1 -- that's not apparent to me.)

[rdroog]

@merceyz: could you please re-open this issue? I'm encountering it on yarn v2.4.1, so your assumption that this is fixed in yarn v2 is incorrect.

Yarn version: 2.4.1
Node version: 14.17.0
Platform: macOS 11.5.1 (Big Sur)

[merceyz]

@rdroog Open a new issue with a reproduction for v2 if that's the case https://github.com/yarnpkg/berry

[tboulis]

What worked for me was to delete node_modules and run yarn again. The error was gone after that.

rm -rf node_modules && yarn

Hope it helps someone

[perplexyves]

TL;DR

If all the previous solutions did not work with You, try this:

1. Run:

yarn config set "strict-ssl" false -g

2. Try again the installation

[mdwt]

I struggled with the same issue, on yarn 1.22.* with workspaces and nohoist:

"workspaces": {
  "packages": [
    "packages/*"
  ],
  "nohoist": [
    "**"
  ]
},

In my case, it always failed in a specific package's dev dependencies (the "shared" package that contains types and code shared across the repo, and a lot of times eslint or dependencies/plugins of eslint), so I removed all eslint and some other dev dependencies and the error went away. The workspace has 16 packages, a lot of which have eslint dependencies.

I also did yarn cache clean because of what I read in related issue threads, but I'm unsure if that made a difference.