Skip to content

EACCES, Permission denied when writing to subdirectories #313

wachunga opened this Issue Feb 24, 2012 · 17 comments

8 participants


My app can't write to a subdirectory:

var file = path.normalize(__dirname + '/db/test.json');

fs.writeFile(file, JSON.stringify(stuff), function (err) {
    if (err) {
        console.log("Couldn't write file.");
        throw err;


Error: EACCES, Permission denied '/app/db/test.json'

It looks like this may be by design, but I find it severely restrictive. I don't want to clutter the root of my app with created files.

If this is by design, is there any kind of workaround? My app allows people to create projects, and I'd like to write out a file for each into a subdirectory.


We are tracking similar issues under tickets 296 and 284. Writing and reading files to/from your application's sandbox is permitted. The most common issue is not having the directory created in your file system on nodester. Remember that git does not create the directory if there are no files in it - so add a temp file to it before pushing.


I confirmed that the directory exists (using path.exists) before creating this issue, so that's not the problem. I also tried deleting and recreating my app in case that helped, but no love. My issue sounds very similar to #296... I was getting EBADF sometimes.

While trying to debug this, btw, I had trouble figuring out what version of node I was dealing with. Could this be revealed via nodester status or something?


Good idea. We should add the node.js version to nodester status. We are currently running 0.4.9.


BTW, I am a little stumped on these file / sandbox writes at the moment. I need to find some time to do a deep dive on this issue - unless someone figures it out before me.


Good to know re: 0.4.9. Btw, I've managed to workaround this permissions issue by setting an env variable and saving files in root when running on nodester.

Not ideal, but works for now. Maybe others can use a similar workaround.

nodester commented Mar 2, 2012

We made a permission change on the directories. Would it be possible for you to create a new app on nodester and re-test your previous method to see it this resolves the issue?


I'm having the same issue reading/writing to things in sub directories. I tested it just an hour ago.

TheX commented Mar 4, 2012

Has anyone a solution? Or is this problem fixed?


TheX I'm still having problems with this.

@alejandro alejandro added a commit that referenced this issue Mar 16, 2012
@alejandro alejandro [master] Added npm#force command, to install dependencies inside app …
…dir not chroot. Maybe a fix to #284  #313 but mostly with trammi module

Sorry guys ^^ this is not the fix. I'll pushing those changes soon...


I am having a similar problem, has this been fixed?


I also have this problem. Here is my minimally reproducible test case. Create a new app with nodester create, and add the following line:

fs.writeFileSync(__dirname + '/public/test.html', 'hello, node');

This breaks. Nodester admins can check out my app at, but its offline due to that line. This shouldn't be happening, given that /public already exists in the repo.

Spawing /app/server.js
Running node v-0.8.1


  return, stringToFlags(flags), mode);
Error: EACCES, permission denied '/app/public/test.html'
    at Object.fs.openSync (fs.js:338:18)
    at Object.fs.writeFileSync (fs.js:756:15)
    at Object.<anonymous> (/app/server.js:17:4)
    at Module._compile (module.js:449:26)
    at Object.Module._extensions..js (module.js:467:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.runMain (module.js:487:10)
    at process.startup.processNextTick.process._tickCallback (node.js:244:9)

Error: Restarted too many times, bailing.

Sorry @vincentwoo , @dnnsmanace, @JustMaier, @TheX and @wachunga because of the way nodester works we can't provide this. We need to keep the environment and the server in the best conditions and having the hability to do fs operations (write) introduces a lot of problems, problem that we want to avoid. (a.k.a bad users -> - resources).

Everything else is accessible to you and we are open to ideas and/or suggestions.

Hack the planet \m/


P.S. This is issue closes #313, #296 and #284.

@alejandro alejandro closed this Jul 8, 2012
wachunga commented Jul 8, 2012

@alejandromg does that mean all fs operations will be restricted in the future? Currently they only fail in subdirectories.

In either case, I suggest adding some documentation to save some headaches.


@wachunga not really. You can do reads, stats, and the others operations. They are and they'll be available.

The only missing is write to disk. We actually have documented some of them:

Until today, we are tracking some EACCESS errors, for those trying to write files to the server you better wait for it. | here

But yes that can be a little bit more useful. I'll update the docs so we can have a better reference for this.



This is a deal-breaker for me. If you are concerned about bad users/resources, can't you impose some sort of cap on how much disk space an app can use? I believe the app directories are already chrooted.


@vincentwoo we have a solution (node-watcher) ;).

As I said we are really sorry for all the problems and yes we are looking for better solutions. We are/were working on this, but this goes beyond our scope and the cost-benefit is a little expensive to mantain. And also we are trying to change the use of chroots with one more "flexible". So maybe in nodester*next ™ we'll have a better support for write operations.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.