Error "EPERM: operation not permitted, lstat ..." when deployed to full IIS with restricted permissions #597

New Issue

fergalmoran · 2025-08-09T17:16:54Z

fergalmoran commented

2025-08-09 17:16:54 +00:00

Originally created by @SteveSandersonMS on 7/11/2017

In a typical IIS deployment, the application runs as a user that only has permission to read the filesystem at the level of the application and below. It does not usually have permission to read any attributes of ancestor-level directories.

This causes Node to throw an error when it tries to load any module. For example, if the module file was at C:\Users\username\apps\myapp1\, the IIS user would typically have access to read attributes of C:\ and C:\Users, but not C:\Users\username, so Node would throw:

Error: EPERM, operation not permitted 'C:\Users\username'
    at Error (native)
    at Object.bindingFs.lstat ([eval]:1:138)
    at Object.fs.lstatSync (fs.js:796:18)
    at Object.realpathSync (fs.js:1387:21)
    at tryFile (module.js:135:15)
    at Function.Module._findPath (module.js:174:18)
    at Function.Module._resolveFilename (module.js:334:25)
    at Function.Module._load (module.js:278:25)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)

The underlying issue is a bug which was already reported to Node, i.e., that Node tries to walk along the file path to the module, starting from the disk root, reading the attributes of each directory to see whether or not it's a symlink. It's fine to do that in typical Linux/macOS cases, but is not at all fine in typical Windows cases.

This affects all uses of NodeServices (both the SPA templates, and any standalone usage) for applications deployed to IIS, such as those deployed to a local IIS instance by Visual Studio.

*Originally created by @SteveSandersonMS on 7/11/2017* In a typical IIS deployment, the application runs as a user that only has permission to read the filesystem at the level of the application and below. It does *not* usually have permission to read any attributes of ancestor-level directories. This causes Node to throw an error when it tries to load any module. For example, if the module file was at `C:\Users\username\apps\myapp1\`, the IIS user would typically have access to read attributes of `C:\` and `C:\Users`, but *not* `C:\Users\username`, so Node would throw: ``` Error: EPERM, operation not permitted 'C:\Users\username' at Error (native) at Object.bindingFs.lstat ([eval]:1:138) at Object.fs.lstatSync (fs.js:796:18) at Object.realpathSync (fs.js:1387:21) at tryFile (module.js:135:15) at Function.Module._findPath (module.js:174:18) at Function.Module._resolveFilename (module.js:334:25) at Function.Module._load (module.js:278:25) at Module.require (module.js:365:17) at require (module.js:384:17) ``` The underlying issue is [a bug which was already reported to Node](https://github.com/nodejs/node-v0.x-archive/issues/3977), i.e., that Node tries to walk along the file path to the module, starting from the disk root, reading the attributes of each directory to see whether or not it's a symlink. It's fine to do that in typical Linux/macOS cases, but is not at all fine in typical Windows cases. This affects all uses of NodeServices (both the SPA templates, and any standalone usage) for applications deployed to IIS, such as those deployed to a local IIS instance by Visual Studio.

fergalmoran closed this issue

2025-08-09 17:16:54 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/JavaScriptServices#597