Node.js crash on Windows when no read permissions for the disk root.

[rukeba]

Node.js will crash with the error "Error: EPERM, operation not permitted 'C:'" if read permissions to the disk root are disabled. This situation happens often in a shared hosting environment since users only have permissions for certain folders and not the entire hard drive.

looking for "D:\\HostingSpaces\\misha1\\misha1.com\\wwwroot\\app.js" in ["D:\\HostingSpaces\\misha1\\misha1.com\\wwwroot\\node_modules","C:\\Program Files (x86)\\lib\\node"]

fs.js:520
  return binding.lstat(pathModule._makeLong(path));
                 ^
Error: EPERM, operation not permitted 'D:\'
    at Object.fs.lstatSync (fs.js:520:18)
    at start (fs.js:1017:10)
    at Object.realpathSync (fs.js:1005:3)
    at tryFile (module.js:142:15)
    at Function.Module._findPath (module.js:181:18)
    at Function.Module._resolveFilename (module.js:336:25)
    at Function.Module._load (module.js:280:25)
    at Module.runMain (module.js:492:10)
    at process.startup.processNextTick.process._tickCallback (node.js:244:9)

node -v
v0.8.8

[piscisaureus]

Can you not give "read attributes" permission to users?

[rukeba]

This is a requirement if you build a shared hosting on Windows with IIS and want to host Node.js apps. Most hosting control panels will remove C:\ (disk root) read permissions to prevent users from reading other's folders, like on this page: http://www.websitepanel.net/kb/how-to-prevent-users-to-access-other-users-folder
I think there should be at least some try/catch near the fs.js:520 line to prevent node from crashing.
Node is running fine if you execute it from command line with your user (admin) permissions, but when you start it form IIS web server to host a web site it will be started with restricted permissions and crash.

[piscisaureus]

In order to find the full path to node.exe and app.js, node lstat()s all directories in it's path (so c:\, c:\program files, c:\program files\nodejs). Node does this to (a) fill out the process.execPath property and (b) use the correct module loading semantics.

In order to make node work, allow all users to "read file attributes" on the 3 paths I mentioned. This is not a security risk.

http://screencast.com/t/GTI3fozolv

[piscisaureus]

Er, you'll probably want to select "apply to this file/folder only".

[govorunov]

It is not the problem that node cannot find an app.js script. In fact it can.. or it would if it wouldn't crash before on trying accessing optional c:\ I understand that node is searching for scripts and modules in many optional locations, but why would it crash if any of these optional locations is inaccessible because of permissions? I think it needs to gracefully move to the next possible location without crash.

[piscisaureus]

@govorunov @rukeba The problem is that node tries to resolve any symlinks in the path of the main module.

[trevnorris]

@piscisaureus still a thing?

[piscisaureus]

WONTFIX for now.

[pksorensen]

This is still a problem. There are situations where giving these permissions are not allowed in shared hosting. Composite C1 (CMS) is using this to compile .less where these permissions are not given. Here is the call stack.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: System.InvalidOperationException: Compiling less caused a scripting host error. 
fs.js:679
 return binding.lstat(pathModule._makeLong(path));
                ^
Error: EPERM, operation not permitted 'd:\web'
   at Object.fs.lstatSync (fs.js:679:18)
   at Object.realpathSync (fs.js:1265:21)
   at tryFile (module.js:142:15)
   at Function.Module._findPath (module.js:181:18)
   at Function.Module._resolveFilename (module.js:336:25)
   at Function.Module._load (module.js:280:25)
   at Function.Module.runMain (module.js:497:10)
   at startup (node.js:119:16)
   at node.js:901:3