Can't run app because of permission in macOS v11 (Big Sur)
MacosMacos Big-SurMacos Problem Overview
I installed macOS v11 (Big Sur) yesterday and since then I am not able to run some old application. This is the message I get:
> You do not have permission to open the application
I think this application is from an unknown developer.
I tried different methods that were working in macOS v10.15 (Catalina) like:
spctl --master-disable
Or I tried also to disable SIP and AMFI.
I've also tried:
sudo xattr -rd com.apple.quarantine /Applications/my_app.app
If I run the application from the terminal, this is the text version of the error I get:
> The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10826 "kLSNoLaunchPermissionErr: User doesn't have permission to launch the app (managed networks)" UserInfo={_LSFunction=_LSLaunchWithRunningboard, _LSLine=2508, NSUnderlyingError=0x7fcb24c13ec0 {Error Domain=RBSRequestErrorDomain Code=5 "Launched process exited during launch." UserInfo={NSLocalizedFailureReason=Launched process exited during launch.}}}
Also tried to disable encryption and run:
csrutil authenticated-root disable
This is the error window:
Macos Solutions
Solution 1 - Macos
I had this problem with the error "Termination Reason: Namespace CODESIGNING, Code 0x1" and I managed to open the application after I signed it again on that machine, with the command:
codesign --force --deep --sign - /Applications/AppName.app
No other solution worked for me.
Solution 2 - Macos
I too had faced the same problem with this error. My DBeaver did not work while I opened after a week of not using it:
> You do not have permission to open this application.
I even checked system preferences. It showed accepts in security. My current OS is macOS v11 (Big Sur).
So I tried in the terminal:
Step 1: sudo spctl --master-disable
-> did not work
Step 2: xattr -rd com.apple.quarantine DBeaver
-> did not work
Step 3: Then I opened DBeaver in the terminal and ran sudo chmod -R 777
-> again, it did not work
Step 4: Finally I tried:
codesign --force --deep --sign - /Applications/DBeaver.app
Wow, it works great. Now my DBeaver is working good.
Solution 3 - Macos
Open Terminal or iTerm and type sudo chmod -R 755
, then drag the .app
into the window, which will bring the full path into Terminal or iTerm. This worked for me, moving the -R
option directly after chmod
.
It will look like this:
sudo chmod -R 755 Path\ to\ app\ file.app
Press return.
Solution 4 - Macos
It seems to be a permissions issue on one of the files deep in the .app that you moved to the applications directory.
Open Terminal or iTerm and type "chmod -R 755 " and drag the .app into the window, which will bring the full path into Terminal or iTerm.
It will look like this:
chmod -R 755 Path\ to\ app\ file.app
Press return
Then, you can open the app file normally, but it will fail because gatekeeper won't be able to verify the file. From there, go into your "Security and Privacy" in "System Preferences" and then click to allow the app to open.
Solution 5 - Macos
The problem in my case it was related to a Big Sur problem where UPX compressed binaries are not recognised properly, so they were not executed with a permission error.
There is some more information here: UPX compressed application fails to start on latest macOS release: Big Sur 11.01 #424
So the solution is to unpack the binary with UPX and run it normally.
Install upx with Homebrew (executable brew
):
brew install upx
Now run this command:
sudo upx -d /Applications/my_app.app/Contents/MacOS/my_app
(Please note you have to specify the full binary path.)
You should use the path of your binary instead of "/Applications/my_app.app/Contents/MacOS/my_app"
Then run the application normally.
Solution 6 - Macos
I found a solution:
-
You need to resign the app, (install Xcode tools, if necessary):
xcode-select --install sudo codesign --force --deep --sign - /Applications/YourAppName.app
-
Move the app to quarantine:
sudo xattr -d -r com.apple.quarantine /Applications/YourAppName.app
-
Go to
/Applications/YourAppName.app/Contents/MacOs
and make the file inside executable:sudo chmod +x Script_name
That worked for me and the app launched.
Solution 7 - Macos
This answer will only apply to a specific set of applications
I had this issue with a universal binary (Terminal) that I duplicated and explicitly set in the info "Open using Rosetta" to run x86 tools like Homebrew. After updating to 11.0.1 from 11.0.0, the x86 version of the terminal stopped working with the above error.
I simply had to delete the duplicate, created another duplicate of the terminal and enabled Rosetta again.
Solution 8 - Macos
First figure out that your application signature is valid:
From Apple's official website:
> All apps in the App Store are signed by Apple to ensure they have not been > misused or tampered with. Apple signs any app that comes with Apple > devices.
To check this out, you can type the following in your terminal (the path of Folx.app is just for an example and you should replace it with your desired app):
pkgutil --check-signature /Applications/Folx.app
if you get an "invalid signature" responce, something like this:
Then your app maybe was installed in some hacky way! And now your easiest approach is to uninstall the app and reinstall it again.
Otherwise, you will have plenty of hard time to enjoy () with that app, Xcode, and signature stuff...
Solution 9 - Macos
You have to run SUDO xattr -d com.apple.quarantine <app>. It's important that you don't forget sudo or it won't work.
Solution 10 - Macos
This is the only solution that worked in my case.
Download macOS-GateKeeper-Helper.
-
Open GateKeeper_Helper.command by double-clicking on it (if it says untrusted developer, go ahead and run it from Settings - Security & Privacy - General - Open Anyway)
-
Select Option 4 (Remove app from GateKeeper quarantine)
-
Drag and drop the app file from the Applications folder, hit the Return key, and enter your password
-
You will see a message like “App removed from quarantine”. That’s it. Try to open the app as usual.
Solution 11 - Macos
We just removed In-App purchases from capabilities and it worked (the app is distributed from the company site https://nektony.com/mac-app-cleaner).
Actually, it removed "StoreKit.framework" from the project file.
Solution 12 - Macos
I encountered this issue when sending to a colleague for testing a Mac app that I developed. He tried some of the suggestions on this forum, but they didn't seem to work (and we're both on Intel, so the Rosetta tips didn't apply).
What ultimately worked for me was creating a blank disk image, and then adding the .app file to the image and then sending him the disk image. It seems like the problem comes up when the .app file is compressed, and adding the file to a disk image first seems to help prevent the issue.
Solution 13 - Macos
If you are uploading an Xcode app to GitHub releases, make sure to compress it first on your computer, don't let GitHub compress it.
Solution 14 - Macos
For my team, this turned out to be a problem with Git adding CRLF to the Entitlements.plist file.
Once I fixed the .gitattributes file to only use LF with p-list files, I built a new app and had it codesigned and it worked--no aborts. I also had to make sure Jenkins wiped the workspace since it didn't seem to fix the file at first.
Solution 15 - Macos
sudo chmod -R 777 /app/to/path
This is the only thing that worked for me after trying everything from the answers.
Solution 16 - Macos
I've faced similar kind of permission issues and nothing helped. At the end, reinstalling the application, in which I was facing the issues, helped me.
Still I don't know why this problem had occurred.
Solution 17 - Macos
Check in which Applications folder is your app, if it's not in your user one (most of your apps are there, e.g. Google Chrome, FaceTime), move the app there and try to open it again, this worked for me
Solution 18 - Macos
None of these solutions worked for me. Updating to macOS v11.4 (Big Sur) fixed the issue in my case.