yarnpkg
[Bug?]: Error: EXDEV: cross-device link not permitted
Self-service
- [ ] I'd be willing to implement a fix
Describe the bug
Any yarn dlx command ends with error on Linux because it tries to link tmp file system and local one.
To reproduce
yarn dlx @yarnpkg/sdks vscode (for example)
Result:
➤ YN0000: · Failed with errors in 3s 660ms
node:internal/process/promises:391
triggerUncaughtException(err, true /* fromPromise */);
^
[Error: EXDEV: cross-device link not permitted, link '/home/xxx/.yarn/berry/i
ndex/52/5220208b882bf713918c25d953de5127c523db71.dat' -> '/tmp/xfs-3c6297d8/dlx-30
676/node_modules/.store/@yarnpkg-sdks-npm-3.2.0-03b1f3c8a8/package/README.md'] {
errno: -18,
code: 'EXDEV',
syscall: 'link',
path: '/home/xxx/.yarn/berry/index/52/5220208b882bf713918c25d953de5127c523db71.dat',
dest: '/tmp/xfs-3c6297d8/dlx-30676/node_modules/.store/@yarnpkg-sdks-npm-3.2.0-03b1f3c8a8/package/README.md'
}
Environment
System:
Linux OpenSuse Leap 15.6 (6.4.0 kernel)
Binaries:
Node.js v20.15.1
Yarn 4.4.0
Additional context
It is really simple error, read how-to-fix-nodejs-error-exdev for workaround.
Looks like a duplicate of #6497? See https://github.com/yarnpkg/berry/issues/6497#issuecomment-2354963762
Looks like a duplicate of #6497? See #6497 (comment)
Yes, the source of problem is the same - hardlinks. But we should not use links between temporary folder and any other at all, cause temporary partition may has different file system by design.
Hi! 👋
It seems like this issue as been marked as probably resolved, or missing important information blocking its progression. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it.
The problem is you are explicitly requesting two conflicting constraints for Yarn:
- Hardlink all packages to the global store
- Install this package into the temp folder
Do we ignore one of them? If so, which one?
If we ignore 1, all dlx calls will use up much more space in the temp folder. This may be unexpected to the user given they expect packages to hardlink to the global store, and may cause problems given that some systems do not clean the temp folder by default.
If we ignore 2, then where do we install the package?
In more general terms, the problem is using an install strategy that involves hardlinking to a global store system-wide, when projects on that system are spread across multiple devices.
FWIW pnpm also suffers from it, but they solved it simply by having multiple stores. Personally I don't think just putting stuff everywhere is a great solution, especially given that it is happening silently.
Maybe we can add a config for users to opt into that behavior?
cc @frg2089
In more general terms, the problem is using an install strategy that involves hardlinking to a global store system-wide, when projects on that system are spread across multiple devices.
@clemyan, you are absolutely right. This part from pnpm FAQ tells the same: "The package store should be on the same drive and filesystem as installations, otherwise packages will be copied, not linked. This is due to a limitation in how hard linking works, in that a file on one filesystem cannot address a location in another."
The current problem with yarn - trying to use link without checking for error condition. The right behavior - break installation process from the start with warning message that your project and package storage are on different devices/FS and could not be linked.
And the user should decide for himself - move project or storage location. But I want to return to an important point once again. When a user choose another drive for both places, we should NOT use link mechanic from Temp folder to outside, cause it is 100% that temporary folder on another drive (or filesystem volume).
Hi! 👋
It seems like this issue as been marked as probably resolved, or missing important information blocking its progression. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it.
I had the same issue.
I created an APFS volume on my macOS called workspaces to house the code repository in my work, and I had a cross-device link not permitted issue when using the configuration of nodeLinker: pnpm.
Yarn 4.9.2
[Error: EXDEV: cross-device link not permitted, link '/Users/garfield/.yarn/berry/index/f8/f8670c99ff420049dae263cf98c1e83764bdb487.dat' -> '/Volumes/workspaces/******/node_modules/.store/@ag-grid-community-locale-npm-34.0.2-9741bbe3bf/package/package.json'] {
errno: -18,
code: 'EXDEV',
syscall: 'link',
path: '/Users/garfield/.yarn/berry/index/f8/f8670c99ff420049dae263cf98c1e83764bdb487.dat',
dest: '/Volumes/workspaces/******/node_modules/.store/@ag-grid-community-locale-npm-34.0.2-9741bbe3bf/package/package.json'
}
Node.js v22.14.0
Please let me know if I'm being dumb, or have missed some memo that makes this a non-issue.
It would be cool if Yarn Berry offered graceful fallback behavior for this, as I'd like to use nodeLinker: pnpm and have been doing so locally, but it turns out on GitLab CI we encounter this issue due to an attempt to cross-device hard link.
➤ YN0000: ┌ Link step
Link step 00:01
➤ YN0001: Error: EXDEV: cross-device link not permitted, link '/root/.yarn/berry/index/e9/e9cc6f57245f90867a48da3b38244d973fef5d20.dat' -> '/builds/SethFalco/matrix-stream-alerts/node_modules/.store/@eslint-js-npm-9.34.0-231809f5e2/package/LICENSE'
➤ YN0000: └ Completed in 1s 209ms
➤ YN0000: · Failed with errors in 5s 273ms
node:internal/process/promises:394
triggerUncaughtException(err, true /* fromPromise */);
^
[Error: EXDEV: cross-device link not permitted, link '/root/.yarn/berry/index/e9/e9cc6f57245f90867a48da3b38244d973fef5d20.dat' -> '/builds/SethFalco/…
If we can not utilize the benefits of this option to it's fullest on all environments, it is unfortunate but tolerable. But if committing a .yarnrc.yml makes it so that we can't build the project at all on some environments, it's not a very stable choice as a project maintainer.
Rather than outright fail, I would rather see Yarn log a warning and copy instead of hard link. This seems like a fair compromise to improve the usability of nodeLinker: pnpm while still letting users know of the conflict between their configuration and environment.
If this was a system-wide setting maintained outside the repository, I would appreciate breaking the build. But this setting is configured per project, and nodeLinker: node-modules seems like the only viable option if we wanted something that works reasonably well in all environments.
Alternatively, feel free to let me know if I've missed the memo, and this is something that is meant to be configured system-wide or if there is another workaround for CI environments.
Meanwhile, I can confirm switching to nodeLinker: node-modules does resolve the problem on GitLab CI.
