Skip to content

EACCES, Permission denied when writing to subdirectories #313

Closed
wachunga opened this Issue Feb 24, 2012 · 17 comments

8 participants

@wachunga

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;
    }
});

yields:

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.

@chrismatthieu
Collaborator

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.

@wachunga

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?

@chrismatthieu
Collaborator

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

@chrismatthieu
Collaborator

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.

@wachunga

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
Owner
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?

@JustMaier

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

@TheX
TheX commented Mar 4, 2012

Has anyone a solution? Or is this problem fixed?

@JustMaier

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
cbbb414
@alejandro
Collaborator

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

@denisnazarov

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

@vincentwoo

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 writer.nodester.com, 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


fs.js:338

  return binding.open(pathModule._makeLong(path), 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.
@alejandro
Collaborator

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/

/be

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

@alejandro alejandro closed this Jul 8, 2012
@wachunga
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.

@alejandro
Collaborator

@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.

/be

@vincentwoo

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.

@alejandro
Collaborator

@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.

/be

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.