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

fs.symlink can’t create directory symlinks on Windows #18518

Closed
chris-morgan opened this issue Feb 2, 2018 · 16 comments
Closed

fs.symlink can’t create directory symlinks on Windows #18518

chris-morgan opened this issue Feb 2, 2018 · 16 comments
Labels
fs Issues and PRs related to the fs subsystem / file system. windows Issues and PRs related to the Windows platform.

Comments

@chris-morgan
Copy link

chris-morgan commented Feb 2, 2018

  • Version: v8.9.4
  • Platform: Windows 10, 64-bit, build 17083 (Windows Insider Preview). In developer mode (so normal users can create symlinks).
  • Subsystem: fs

Using fs.symlinkSync( x, y, 'dir' ) to create a directory symlink is failing (EPERM: operation not permitted), while mklink /d is able to make the symlink.

Simplest example to demonstrate the issue:

C:\Users\me\AppData\Local\Temp>node
> require('fs').symlinkSync('abcdef', 'ghijkl', 'dir')
Error: EPERM: operation not permitted, symlink 'abcdef' -> 'C:\Users\me\AppData\Local\Temp\ghijkl'
    at Object.fs.symlinkSync (fs.js:1014:18)

File symlinks are fine; it’s only directory symlinks that are failing. It doesn’t matter whether the target path exists or not, it fails with the same EPERM error.

Meanwhile,

C:\Users\me\AppData\Local\Temp>mklink /d ghijkl abcdef
symbolic link created for ghijkl <<===>> abcdef
@starkwang starkwang added the fs Issues and PRs related to the fs subsystem / file system. label Feb 2, 2018
@bnoordhuis bnoordhuis added the windows Issues and PRs related to the Windows platform. label Feb 2, 2018
@seishun
Copy link
Contributor

seishun commented Feb 2, 2018

Can't reproduce on master.

@seishun
Copy link
Contributor

seishun commented Feb 2, 2018

It was fixed in a083786 (PR: #18260). cc @nodejs/lts

@chris-morgan
Copy link
Author

For an idea of the context of this: ghost-cli creates a directory symlink as part of ghost install local, and if it fails then the result is incomplete and non-functional, so it’s broken on Windows. Having WSL, I worked around that by installing ghost-cli on the Ubuntu side instead of the Windows side, but that’s a workaround rather than a fix.

@bnoordhuis
Copy link
Member

The libuv upgrade will make its way into node 8 eventually. Since there is nothing to do but wait I'll go ahead and close this out.

The relevant libuv PR: libuv/libuv#1706

@livingstonef
Copy link

This is still a problem. Any update?

@chris-morgan
Copy link
Author

@livingstonef I now have 8.11.1, and it’s fixed there. If you have an older version of Node, try upgrading. If it’s the same or newer, ensure your Windows installation is in Developer Mode, and then please verify that my “simplest example to demonstrate the issue” does in fact not work for you; if it does work, then you probably have a different issue.

@flotwig
Copy link

flotwig commented Jul 22, 2019

fs.symlink appears to require admin privileges on Windows 10 for some reason. If anyone else runs into this, try running as admin.

@chris-morgan
Copy link
Author

@flotwig For historical and security reasons, it requires either admin privileges, or for the machine to be in developer mode and the appropriate flag set in the API call (and that flag was what was missing). But yeah, this was fixed over a year ago now.

@flotwig
Copy link

flotwig commented Jul 22, 2019

Yeah, we're still using Node 8.9.3 (though upgrading soon!)

FWIW, I actually needed to pass type=junction to fs.symlink, that made running as admin unnecessary and made the symlinks actually work.

@OLEREO
Copy link

OLEREO commented Sep 23, 2021

是的,我们仍在使用 Node 8.9.3(尽管很快就会升级!)

FWIW,我实际上需要传递type=junctionfs.symlink,这使得以管理员身份运行变得不必要并使符号链接实际工作。

Yeah, we're still using Node 8.9.3 (though upgrading soon!)

FWIW, I actually needed to pass type=junction to fs.symlink, that made running as admin unnecessary and made the symlinks actually work.

There are still some problems. Folders are created correctly, but the files are also recognized as folders and the soft links created do not work.

@citkane
Copy link

citkane commented Aug 24, 2022

#18518 (comment)

FWIW, I actually needed to pass type=junction to fs.symlink, that made running as admin unnecessary and made the symlinks actually work.

Still true in node v16.17.0

@ghost
Copy link

ghost commented Feb 5, 2023

This bug is still occurring on Node v18 LTS. Has this been fixed by a higher niode version? If not, this issue either needs to be reopened or referenced in a new issue.

@bnoordhuis
Copy link
Member

@IRod22 v18.x never had this issue. I suspect you're misunderstanding the discussion here.

@ghost
Copy link

ghost commented Feb 5, 2023

@bnoordhuis I am investigating a bug for imba/imba#768 where Node throws a EPERM error because Windows does not permit Node to create a symlink without administrative permissions. I did some googling, and the search results led me to this discussion.

@ghost
Copy link

ghost commented Feb 7, 2023

Here's my node version:

> node -v
v18.12.1

@lqzhgood
Copy link

lqzhgood commented Apr 15, 2023

fs.symlink api need runnning as admin. but mklink don't

v18.16.0
windows 11
// need admin
// err.message EPERM: operation not permitted, symlink 'E:\Git\xx\i' -> 'E:\Git\xx\o'
fs.symlinkSync('i', 'o')
// this is ok
const { execSync } = require('child_process');
execSync('mklink /J o i', { windowsHide: true });

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fs Issues and PRs related to the fs subsystem / file system. windows Issues and PRs related to the Windows platform.
Projects
None yet
Development

No branches or pull requests

9 participants