Electron-packager: resources/app folder has broken permissions

Created on 20 Jun 2016  路  11Comments  路  Source: electron/electron-packager

The /resources/app folder can't be deleted because its permissions are somehow broken. I get this error either by trying to package as an asar or when trying to overwrite a previous build when using the Programmatic API with electron-packager installed locally in the folder.

{ Error: EPERM: operation not permitted, rmdir 'D:\user\appNameFolder\appName-win32-x64\resources\app'
  at Error (native)
  errno: -4048,
  code: 'EPERM',
  syscall: 'rmdir',
  path: 'D:\\user\\appNameFolder\\appName-win32-x64\\resources\\app' }

When I use command line using the global package.

EPERM: operation not permitted, rmdir 'C:\Users\User\AppData\Local\Temp\electron-packager\win32-x64\appName-win32-x64\resources\app'

After this error occurs, I can delete the app folder myself but I can't using the rmdir Windows command and it returns "Access is Denied". If I check the permissions through the properties window it has the same settings as any other folder. I'm not sure what's causing this error and I've tried investigating but haven't gotten anywhere so far.

I figured it might be problem with npm but I've tried reinstalling npm and nodejs multiple times to no avail.

After the error occurs once with the command line, using it a second time will cause no console output. This can be fixed by deleting the AppData/Local/Temp/electron-packager folder. It gets stuck here because it doesn't have permission to delete the app folder from the previous build.

Which version of electron-packager are you using?

7.0.4

What CLI arguments are you passing? Alternatively, if you are using the API, what parameters are
you passing to the packager() function?

for the packager() function

const options = {
    platform: 'win32',
    arch: 'x64',
    dir: '.',
    version: '1.2.3',
    tmpdir: false,
    asar: true,
    overwrite: true
};

for the command line

electron-packager . --platform=win32 --arch=x64 --version=1.2.3

Although I have tried many other options with no success.

What version of Electron are you building with?

Tried 1.2.1 and 1.2.3

What is the host platform are you running electron-packager on?

Windows 10 x64

What target platform(s)/architecture(s) are you building for?
win32 x64

Please provide either a failing testcase or detailed steps to reproduce your problem.
Installing it both globally

windows needs info

Most helpful comment

Thank you everyone for the help, I finally solved the issue even although I think it wasn't directly related to electron-packager.

I'm not sure how but the folder had been set to read-only. It took a while to realize this because I've never dealt with Windows permission issues before. Everything inside the folder was writable and setting it through the properties window had no effect.

I only found out that it was read-only by using ls in powershell and saw there was an r mode where there shouldn't be. I fixed the issue using the command attrib -R appNameFolder.

All 11 comments

I wonder if this is related to #375, despite not being on OSX?

CC: @jprichardson

It might be related but there are few differences. It still doesn't work using tmpdir=false. Also, I can delete it as a user but not through command line which is the opposite to that issue.

It's been working fine up until recently but I'm not exactly sure what triggered this.

Try an earlier version of electron-packager?

Yeah, I don't think this one is related to #375. Windows has some funky delete issues at times - I'm not saying that's what's going on here, but I've ran into similar strange issues in the past related to these sorts of things.

Possibly related: https://github.com/isaacs/rimraf/issues/105. Also, not the same error, but discusses more Windows related delete issues: https://github.com/isaacs/rimraf/issues/72.

Possible workaround: use asar: true.

Possible, because electron-packager still doesn't create asar directly from app, but copies and only then creates asar archive.

Thank you everyone for the help, I finally solved the issue even although I think it wasn't directly related to electron-packager.

I'm not sure how but the folder had been set to read-only. It took a while to realize this because I've never dealt with Windows permission issues before. Everything inside the folder was writable and setting it through the properties window had no effect.

I only found out that it was read-only by using ls in powershell and saw there was an r mode where there shouldn't be. I fixed the issue using the command attrib -R appNameFolder.

I'm not sure how but the folder had been set to read-only.

Yep, so it was the pesky https://github.com/isaacs/rimraf/issues/105 then.

Yeah looks like it was something to do with that.

After getting this error, trying to repackage doesn't work (or do anything), even using --overwrite. Removing the read-only permission from the app folder as described above and deleting the %localappdata%/Temp/electron-packager/ folder then allows it to work next time

The trouble is, every time I run electron-packager, it creates a read-only folder resources/app/ and a tempdir with the same permissions, so the next time round I get the same problem again

@binaryfunt Are you using SVN for your project? I ran into this issues while using TortoiseSVN for the project.

Recently I tried moving the .svn folder out of my project, then runing attrib -r /d /s on the project root. After that I was able to build repeatedly. (Before that, I had to run the attrib every time, as you stated.)

If I then move the .svn folder back in, it still works. The only explanation I can think of is that TortoiseSVN doesn't like the .svn folder not being readonly, but it applies it in a way that affects the project folder. I'm really grasping at straws here, though.

At this point I am able to rebuild repeatedly without issue. Though if it is SVN, a project update may cause a regression. At the very least, I assume this would have to be done by anyone who checks out the project.

Was this page helpful?
0 / 5 - 0 ratings