Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

yarn install error ENOENT: no such file or directory #4563

Closed
jonathantribouharet opened this issue Sep 27, 2017 · 31 comments
Closed

yarn install error ENOENT: no such file or directory #4563

jonathantribouharet opened this issue Sep 27, 2017 · 31 comments
Assignees
Labels
fixed-in-modern This issue has been fixed / implemented in Yarn 2+.

Comments

@jonathantribouharet
Copy link

jonathantribouharet commented Sep 27, 2017

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
Copy link

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)

@BYK BYK self-assigned this Sep 29, 2017
@ChristianG1984
Copy link

ChristianG1984 commented Oct 26, 2017

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
Copy link

aindlq commented Nov 2, 2017

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
Copy link

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
Copy link
Contributor

jure commented Dec 12, 2017

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

ellismg added a commit to pulumi/pulumi that referenced this issue Jan 29, 2018
We've been hitting issues in CI that look like yarnpkg/yarn#4563 and
our hope is that this addresses the issue
ellismg added a commit to pulumi/pulumi that referenced this issue Jan 29, 2018
We've been hitting issues in CI that look like yarnpkg/yarn#4563 and
our hope is that this addresses the issue
ellismg added a commit to pulumi/pulumi that referenced this issue Jan 29, 2018
We've been hitting issues in CI that look like yarnpkg/yarn#4563 and
our hope is that this addresses the issue
@edoshor
Copy link

edoshor commented Mar 19, 2018

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

@kingjerod
Copy link

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
Copy link

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
Copy link

RealAdamSinger commented Jun 13, 2018

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
Copy link

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 <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": [
        "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
Copy link

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
Copy link

domis4 commented Sep 27, 2018

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
Copy link

mike-marcacci commented Nov 30, 2018

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
Copy link

AhtiAhde commented Apr 9, 2019

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
Copy link

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
Copy link

kennethlynne commented Nov 11, 2019

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
Copy link

tombh commented Feb 22, 2020

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.

danielattilasimon added a commit to liquity/dev that referenced this issue May 18, 2020
Buidler is very fragile when used in monorepos:
NomicFoundation/hardhat#468
NomicFoundation/hardhat#532
NomicFoundation/hardhat#570

Let's try using roderik's workaround from here again:
NomicFoundation/hardhat#468

Unfortunately this breaks create-react-app, so try to work around
that by nohoisting the entire dev-frontend package.

Now we need to keep an eye on this problem, because it seems to
occur sometimes:
yarnpkg/yarn#4563

:S
danielattilasimon added a commit to liquity/dev that referenced this issue May 18, 2020
This is an attempt to avoid yarnpkg/yarn#4563
danielattilasimon added a commit to liquity/liquity that referenced this issue May 18, 2020
Buidler is very fragile when used in monorepos:
NomicFoundation/hardhat#468
NomicFoundation/hardhat#532
NomicFoundation/hardhat#570

Let's try using roderik's workaround from here again:
NomicFoundation/hardhat#468

Unfortunately this breaks create-react-app, so try to work around
that by nohoisting the entire dev-frontend package.

Now we need to keep an eye on this problem, because it seems to
occur sometimes:
yarnpkg/yarn#4563

:S
danielattilasimon added a commit to liquity/liquity that referenced this issue May 18, 2020
This is an attempt to avoid yarnpkg/yarn#4563
danielattilasimon added a commit to liquity/liquity that referenced this issue May 19, 2020
Buidler is very fragile when used in monorepos:
NomicFoundation/hardhat#468
NomicFoundation/hardhat#532
NomicFoundation/hardhat#570

Let's try using roderik's workaround from here again:
NomicFoundation/hardhat#468

Unfortunately this breaks create-react-app, so try to work around
that by nohoisting the entire dev-frontend package.

Now we need to keep an eye on this problem, because it seems to
occur sometimes:
yarnpkg/yarn#4563

:S
danielattilasimon added a commit to liquity/liquity that referenced this issue May 19, 2020
This is an attempt to avoid yarnpkg/yarn#4563
@GoMino
Copy link

GoMino commented May 19, 2020

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

@desfero
Copy link

desfero commented Jun 2, 2020

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

@BlueRaja
Copy link

BlueRaja commented Jun 23, 2020

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
Copy link

kiptoomm commented Sep 3, 2020

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"
 }

@ismay
Copy link

ismay commented Dec 1, 2020

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.

danielattilasimon added a commit to liquity/liquity that referenced this issue Dec 16, 2020
Buidler is very fragile when used in monorepos:
NomicFoundation/hardhat#468
NomicFoundation/hardhat#532
NomicFoundation/hardhat#570

Let's try using roderik's workaround from here again:
NomicFoundation/hardhat#468

Unfortunately this breaks create-react-app, so try to work around
that by nohoisting the entire dev-frontend package.

Now we need to keep an eye on this problem, because it seems to
occur sometimes:
yarnpkg/yarn#4563

:S
danielattilasimon added a commit to liquity/liquity that referenced this issue Dec 16, 2020
This is an attempt to avoid yarnpkg/yarn#4563
@Npervic
Copy link

Npervic commented Dec 18, 2020

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

@merceyz
Copy link
Member

merceyz commented Jan 2, 2021

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

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

@merceyz merceyz closed this as completed Jan 2, 2021
@merceyz merceyz added the fixed-in-modern This issue has been fixed / implemented in Yarn 2+. label Jan 2, 2021
@christianchownsan
Copy link

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
Copy link
Member

merceyz commented Jan 18, 2021

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
Copy link

jakerobb commented May 24, 2021

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
Copy link

rdroog commented Aug 2, 2021

@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
Copy link
Member

merceyz commented Aug 2, 2021

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

@tboulis
Copy link

tboulis commented Apr 29, 2022

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
Copy link

TL;DR

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

  1. Run:
yarn config set "strict-ssl" false -g
  1. Try again the installation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fixed-in-modern This issue has been fixed / implemented in Yarn 2+.
Projects
None yet
Development

No branches or pull requests