Npx cap open android -> EACCES

Hi kind strangers,

when doing npx cap open android on Manjaro (Arch) I get:

[x@x x]$ npx cap open android
[info] Opening Android project at: android.
      throw er; // Unhandled 'error' event

Error: spawn /opt/android-studio/ EACCES
    at Process.ChildProcess._handle.onexit (node:internal/child_process:282:19)
    at onErrorNT (node:internal/child_process:477:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
Emitted 'error' event on ChildProcess instance at:
    at Process.ChildProcess._handle.onexit (node:internal/child_process:288:12)
    at onErrorNT (node:internal/child_process:477:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -13,
  code: 'EACCES',
  syscall: 'spawn /opt/android-studio/',
  path: '/opt/android-studio/',
  spawnargs: [

Running android-studio from the same user does work.

Did nothing funny to install Android Studio.
Normal pamac install from AUR stable.

Did chmod 777 -R /opt/android-studio/ to no avail.

[x@x x]$ ls -la /opt/android-studio/
total 60
drwxrwxrwx  7 root root  4096  5. Okt 17:13 .
drwxr-xr-x 13 root root  4096  7. Dez 15:50 ..
drwxrwxrwx  4 root root  4096  5. Okt 17:12 bin
-rwxrwxrwx  1 root root    27  5. Okt 17:10 build.txt
drwxrwxrwx  6 root root  4096  5. Okt 17:12 jre
drwxrwxrwx  5 root root 16384  5. Okt 17:12 lib
drwxrwxrwx  2 root root  4096  5. Okt 17:12 license
-rwxrwxrwx  1 root root 11352  5. Okt 17:10 LICENSE.txt
drwxrwxrwx 57 root root  4096  5. Okt 17:13 plugins
-rwxrwxrwx  1 root root   418  5. Okt 17:10 product-info.json

I’ll do it now in a fresh install vm.

Maybe anyone instantly knows?

ionic info

[x@x x]$ ionic info


   Ionic CLI                     : 6.18.1 (/home/x/.nvm/versions/node/v16.13.1/lib/node_modules/@ionic/cli)
   Ionic Framework               : @ionic/angular 6.0.0
   @angular-devkit/build-angular : 12.0.5
   @angular-devkit/schematics    : 12.0.5
   @angular/cli                  : 12.0.5
   @ionic/angular-toolkit        : 5.0.0


   Capacitor CLI      : 3.3.3
   @capacitor/android : 3.3.3
   @capacitor/core    : 3.3.3
   @capacitor/ios     : 3.3.3


   cordova-res (update available: 0.15.4) : 0.15.3
   native-run                             : 1.5.0


   NodeJS : v16.13.1 (/home/x/.nvm/versions/node/v16.13.1/bin/node)
   npm    : 8.1.2
   OS     : Linux 5.10

Thank you for your time!

I just realized I simply can open the android folder manually in android studio :slight_smile:

1 Like

Never ever ever ever ever do this. Every file in that folder is now a rootkit waiting to happen. Delete the entire directory and reinstall everything in there.

1 Like

I had to add the following items to my PATH variable on my Linux Mint machine. I believe the EACCES error is actually misleading. When I had it, it was NOT a permission issue but a path issue.

export CAPACITOR_ANDROID_STUDIO_PATH=/opt/android-studio/bin/
export ANDROID_SDK_ROOT=$HOME/Android/Sdk
export PATH=$PATH:$ANDROID_SDK_ROOT/tools/bin           # avdmanager, sdkmanager
export PATH=$PATH:$ANDROID_SDK_ROOT/platform-tools      # adb, logcat
export PATH=$PATH:$ANDROID_SDK_ROOT/emulator            # emulator
export PATH=$PATH:$ANDROID_SDK_ROOT/build-tools         # apksigner, zipalign
1 Like

I had to laugh reading your advice :smiley:
I’d never pin sth. like that as the solution - no worries :wink:

But I had to try it before getting on other peoples nerves.
The error sounds too much exactly like file system permissions.

Thank you.

Works like a charm!
I guess the mistake was

export CAPACITOR_ANDROID_STUDIO_PATH=/opt/android-studio/

instead of

export CAPACITOR_ANDROID_STUDIO_PATH=/opt/android-studio/bin/

Thank you soo much for your time!

Awesome! I spent hours over multiple days/weeks trying to figure it out. I was also trying to chase down a permission issue as that is what it looks like from the error message.

I think I originally had:


Thanks for the reminder @rapropos. I think I did 775 when trying to figure out this issue but never changed it back :grimacing: :flushed: :lock:

1 Like

For future reference, a much safer thing to do (still not a wonderful idea, but orders of magnitude better) than chmod is to chown stuff to your ordinary work user. That at least avoids situations where system users can be exploited to write to the area.

1 Like

Ah, yeah for sure. I actually did do that. Owner and group is me. But I still should delete everything and start over now that I know it wasn’t a permission issue :slight_smile: