Skip to content
This repository was archived by the owner on Apr 8, 2020. It is now read-only.

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

Closed
SteveSandersonMS opened this issue Jul 11, 2017 · 6 comments
Milestone

Comments

@SteveSandersonMS
Copy link
Member

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.

@SteveSandersonMS
Copy link
Member Author

SteveSandersonMS commented Jul 11, 2017

Fixed (or at least, temporarily worked around, until Node can really fix the underlying issue) in #1102

SteveSandersonMS added a commit that referenced this issue Jul 12, 2017
Complete the lstat patching for #1101
@theanimashaun
Copy link

theanimashaun commented Jul 18, 2017

Please, how do i get this fix ?

This issue has paused an app in production ? or is there a quick work around ?

@mvndaai
Copy link

mvndaai commented Sep 26, 2017

I had this issue and was able to just use a try/catch to get around this for myself

fs.readdirSync(parentDir).forEach(file => {
    let fp = path.join(parentDir, file);
    let stat;
    try {
         stat = fs.statSync(fp);
    }catch (e){
        switch (e.code){
            case "EPERM":
                console.log("Did not have permission to check file/directory", fp);
                break;
            case "EBUSY":
                console.log("File is busy", fp);
                break;
            default:
                console.log(e);
        }
    }
    if (!stat) return;
    console.log(fp, stat.isDirectory());
});

@idenev
Copy link

idenev commented Oct 6, 2017

@mvndaai Any suggestions where this code should be placed in the angular template? Thanks.

@mvndaai
Copy link

mvndaai commented Oct 9, 2017

@idenev I am not exactly sure where you mean by the angular template, do you have an example. I would suggest making a function in your javascript that handles this and then just call it in angular.

@ganjeii
Copy link

ganjeii commented Jan 23, 2018

I was able to get around this by performing an iisreset

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants