yarn install error ENOENT: no such file or directory

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.


Author: Fantashit

12 thoughts on “yarn install error ENOENT: no such file or directory

  1. 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

  2. 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
  3. Getting the same error consistently.

      /usr/local/Cellar/node/8.9.1/bin/node /usr/local/Cellar/yarn/1.6.0/libexec/bin/yarn.js
    Yarn version: 
    Node version: 
      darwin x64
      Error: ENOENT: no such file or directory, lstat '/Users/gary/Documents/code/build/packages/api-core/node_modules/envkey'
  4. 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

  5. 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.

      /usr/local/bin/node /usr/local/Cellar/yarn/1.7.0/libexec/bin/yarn.js install --network-concurrency 1
    Yarn version: 
    Node version: 
      darwin x64
      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 <mike@marcacci-labs.com>",
        "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": [
          "nohoist": [
        "devDependencies": {
          "husky": "^0.14.3"
        "dependencies": {}
    yarn manifest: 
      No manifest
      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.

  6. 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.

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

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

Comments are closed.