ZeroBraneStudio
ZeroBraneStudio copied to clipboard
M1 Mac - You do not have permission to open the application "ZeroBraneStudio"
Kind of a problem and solution. I recently picked up an M1 Mac and after installing and running ZBS I was greeted with the message in the title. After trying a few different permission variations the problem did not appear to be a permission issue. Long story short, it turns out that for Intel code the translation layer, Rosetta 2, is not installed by default. Running this command:
softwareupdate --install-rosetta
from a Terminal installed Rosetta and sent me on my way.
Hope this helps.
Article that explains ways to install Rosetta 2: https://osxdaily.com/2020/12/04/how-install-rosetta-2-apple-silicon-mac/

@dexmar, interesting; thank you for sharing! I noticed that in the article it says the message is "To open AppName, you need to install Rosetta", but your is different. Did you see the other message as well?
At this point there is not much I can do to improve the support, but I'll consider generating universal binaries that support both platforms (https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary). I'll ping you when I have a test branch for you to check if you don't mind.
@pkulchenko Yeah, happy to test!
I did not receive the pop-up message from the article, I received the pop-up that I attached to the post (I didn't think to take a screenshot of the actual pop-up I received so the one I attached I found with a google search). The warning about inadequate permissions sent me down the wrong path. It was only when I discovered the problem that I then tried installing Dropbox, which is not a universal binary, that I did get prompted with the message in the article.
Also, seems a bit of a corner case so maybe not worth the effort? Since ZBS was the first Intel binary I tried to run I bumped into this, if Rosetta 2 was already installed it would have been smooth sailing.
The real win would be a native ARM build so maybe worth the effort after all?
Anyway, just thoughts.
Thanks!
The real win would be a native ARM build so maybe worth the effort after all?
Right; the universal binary would include both Intel and ARM versions and it can be configured to prefer native or fall back on emulation. I'll definitely consider doing it that way, although it will require recompiling the binaries.
Is the universal binary available? Just got my new M1 MacBook and would really like to avoid installing Rosetta
Unfortunately not yet,
I have a related M1 issue (happy to open a new issue if required); but when trying to debug there is an error loading luasocket:
error loading module 'socket.core' from file '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/socket/core.dylib':
dlopen(/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/socket/core.dylib, 0x0006): tried: '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/socket/core.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/usr/local/lib/core.dylib' (no such file), '/usr/lib/core.dylib' (no such file)
Any ideas on a solution for this?
@chrisjake, have you tried installing Rosetta with softwareupdate --install-rosetta
? Or do you mean that you're getting this error with Rosetta installed when running the IDE?
@pkulchenko I have Rosetta installed; and other programs that rely on Rosetta are working correctly.
I am building Lua filters for Pandoc, so I am running the debugger server in ZBS and calling the scripts from the command line (as Pandoc arguments). This worked on my old Intel-based macbook.
Interesting. I don't have access to an M1 environment, but may have later this week and will try to check what may be going on.
@cjdbarlow, I don't see this issue anymore on either M1 or M2 (under Ventura). Can you check the current release of v2.0 to see if that works for you? Thank you.
That issue is resolved, although mobdebug fails to run as (I think?) the socket.dylib is unsigned. Using 2.01 and MobDebug 0.805.
Error running filter scripts/mermaid.lua:
error loading module 'socket.core' from file '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/socket/core.dylib':
dlopen(/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/socket/core.dylib, 0x0006): tried: '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/socket/core.dylib' (code signature in <F89EA95B-AA5A-350F-AA4E-B30E936EBF7B> '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/socket/core.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs), '/System/Volumes/Preboot/Cryptexes/OS/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/socket/core.dylib' (no such file), '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/socket/core.dylib' (code signature in <F89EA95B-AA5A-350F-AA4E-B30E936EBF7B> '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/socket/core.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs)
stack traceback:
[C]: in function 'require'
...neStudio.app/Contents/ZeroBraneStudio/lualibs/socket.lua:12: in main chunk
[C]: in function 'require'
...p/Contents/ZeroBraneStudio/lualibs/mobdebug/mobdebug.lua:107: in main chunk
[C]: in function 'require'
scripts/mermaid.lua:4: in main chunk
@cjdbarlow, thank you for the report; never seen this one before. Is it on M1? What OS version?
M1 Max, Sonoma 14.0
@cjdbarlow, we just tested on the same configuration and it works. Does it work for you on the simplest script? Does it work for you if you run the IDE from the repository (instead of the downloaded package)?
It occurs when I am initiating a script for remote debugging. The use case is Quarto to manipulate a document prior to rendering. Similar to Pandoc filters.
Script:
package.path = package.path .. ";/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/lualibs/mobdebug/?.lua;/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/lualibs/?.lua;"
package.cpath = package.cpath .. ";/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/?/core.dylib"
require('mobdebug').start()
local testVar = "test"
I'm curious why /System/Volumes/Preboot/Cryptexes/OS/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/socket/core.dylib
is showing up in the error message; it does look like you have two installations that may be different signatures. Can you try putting the path first instead of last and maybe assigning it instead of appending, just to make sure that all the libraries are coming from the same installation?
I'm not sure where that is coming from, there is no Applications
in my ...Cryptexes/OS
folder. Nothing like that in /etc/paths
or /etc/manpaths
either. I overwrote the old version of ZBS when I installed the new one.
I've tried both of those, with the same response. Just to be explicit:
package.cpath = "/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs53/?/core.dylib;"
Gives:
Error running filter scripts/mermaid.lua:
error loading module 'socket.core' from file '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs53/socket/core.dylib':
dlopen(/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs53/socket/core.dylib, 0x0006): tried: '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs53/socket/core.dylib' (code signature in <F5B286CD-6887-38D7-BC16-FA56FAB63DBA> '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs53/socket/core.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs), '/System/Volumes/Preboot/Cryptexes/OS/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs53/socket/core.dylib' (no such file), '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs53/socket/core.dylib' (code signature in <F5B286CD-6887-38D7-BC16-FA56FAB63DBA> '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs53/socket/core.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs)
stack traceback:
[C]: in function 'require'
...neStudio.app/Contents/ZeroBraneStudio/lualibs/socket.lua:12: in main chunk
[C]: in function 'require'
...p/Contents/ZeroBraneStudio/lualibs/mobdebug/mobdebug.lua:107: in main chunk
[C]: in function 'require'
scripts/mermaid.lua:4: in main chunk
And the following gives exactly the same thing (diff checked).
package.cpath = "/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs53/?/core.dylib;" .. package.cpath
@cjdbarlow, I found a good explanation for this error here: https://developer.apple.com/forums/thread/706437.
Basically, it indicates that there is a signature mismatch between the application signature and socket/core.dylib signature, but i don't see any. If you run codesign -d -vvv /Applications/ZeroBraneStudio.app
and codesign -d -vvv /Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/socket/core.dylib
you should get a page with various information including TeamIdentifier
. For me it's 7Y9J46RF53
in both cases. It should be the same for all dylib files, as they are all signed together before notarization.
If it still shows different TeamIdentifiers for you, can you try the following:
- Download the new .dmg file for 2.01 from the zerobrane studio website
- Mount the .dmg file, but don't install anything
- cd
/Volumes/ZeroBraneStudio
- Run the same
codesign
commands (just remove/Applications/
from the path) and see if you get any different TeamIdentifiers.
@pkulchenko, both of those give me the same TeamIdentifier
of 7Y9J46RF53
. Is it because of the remote debugger? The program calling the script is quarto
, which presumably has a different Team ID
Yes, could very well be, as the signatures need to match if present (or the quarto
executable needs to be signed with com.apple.security.cs.disable-library-validation
entitlement). If that's the case, you can try running codesign --remove-signature
on core.dylib
or getting the one from the repository, as they don't have signatures and see if it works.
@cjdbarlow, I'll close this one, as it doesn't seem to be IDE-related, but it would be good to confirm if you got it working after removing the signature from core.dylib
in case someone else runs into the same issue. Thanks!