Garageband X Sandboxing

Hi folks,


Just received a report from a user saying our AU is mulfunctioning and cannot start in Garageband 10 on mavericks.

When I tried to load my software at the first time in Garageband 10, a dialog prompted saying "Security Settings need to be lowered blah blah, do you wan to lower the settings?" And after I clicked on "Lowering Security Settings", my unsandboxed AU can be loaded correctly. Then this particular AU is fine. It can always be correctly started, since it is allowed to access samples and setting files (application support) in the HD. 

But when I tried to load my other plugins, that "lowering security settings" dialog did not show so that my plugin cannot be started since some setting files seem not accessible. Is there a way to lower the security settings for all AU?  Now I can only load the very first AU which Garageband gave me the chance to lower the security setting..

After I confirmed this issue myself and searched here and there on the web, I sort of understand it is because if sandboxing AU is exerted by Garageband 10. But how can we convert our over 4GB samples sampler-based plugin to be a sandboxed one? I am wondering. Pack all the samples inside the .component? 

And a KVR post says it will com to Logic Pro X.


thanks in advance.

Check out:


Hi Rail,


Thanks for the tips. I have read throuth the

but haven't tried yet.


Seems that if I have a




key set in the Info.plist, then I should have the access to files read-write?


The doc also says "The "" key. This key is a boolean that indicates that the Audio Component needs arbitrary access to the file system. This is for backward compatibility for Audio Components that have not yet adopted the usage of security-scope bookmarks and/or the usage of the standard file dialog for discovering, accessing and storing persistent references to files on the file system. In a future OS release, this key will not be supported."

So this key is a temporary one, as it tells in the key name..

Just added  and set to true in the info.plist but nothing changed..

Sorry to resume this old thread, but have you ever succeeded in fixing this? I’m having the same problem now

No, but it will not supported in newer macOS releases anyway, so i don’t think this is the way to go.
I store all my plugin related files in $HOME/Music/Audio Music Apps/MyCompany/
(i vaguely remember this was recommended in some apple developer forum…, but i may be wrong)
(This location can be accessed from inside sandbox, Logic uses this directory too)

(BTW if have you installer which creates the folder, be sure that the “Audio Music Apps” folder will not be created with root file permissions, there are some faulty installers from some plugin-vendors around)

1 Like

Me too.

If you use a file/folder id to generate a unique hardware token for your copy protection (as done in OnlineUnlockStatus) be also sure that you choose a file/folder that is accessible from within GarageBand. Otherwise the hardware id will be different in GarageBand and your otherwise unlocked plugin will stay locked in GarageBand. A similar issue exists on 64bit Windows where a 32bit build can get another id from the OS than a 64bit build for the exact same file.

1 Like

It’s strange: I have just tried this method to obtain the path of the real ("/Users/username") home directory from my plug-in, sandboxed inside Garageband, but with much surprise I have been able to create, write and read files without problems from there.

Are we sure that Garageband sandboxing is actually preventing file access outside the sandbox?

IIRC the sandboxed files for GarageBand are located at

It contains shortcuts to some real directories. To these GarageBand has full access.

But it also contains regular directories. The sandboxed stuff. If GarageBand wants to write a file it doesn’t have access, it creates the folder structure and the file here.

Hi all and thanks for replying.

I did some more experimenting and these are the results.
I am summarizing them here in case others (including myself) will need a quick reference to them in the future.

Let’s make it clear that these experiments are about how to load a non-sandbox-safe plug-in in Garageband X.

Also, let’s suppose that we start these with a fresh installation of Garageband X on a new computer.


  1. The first time we try to load a non-sandbox-safe plug-in, we are greeted with the following dialog window

  2. If one responds clicking “Cancel”, the operation is aborted and the plug-in is not loaded at all.

  3. If one clicks “Lower Security Settings”, the plug-in loading proceeds as requested, although with some differences from a regular loading inside a regular, non-sandboxed host. We’ll cover them later.

  4. The “Lower Security Setting” choice made at point 3 is a global setting that gets stored in Garageband.
    This means that when you load the non-sandbox-safe plug-in again, the operation now proceeds without the dialog window being displayed again.
    Also, this applies not only to the plug-in for which the dialog was originally displayed, but also to any other non-sandbox-safe plug-ins: all non-sandbox-safe plug-ins will now be loaded without the dialog being displayed again.

  5. It is possible to reset that security setting so that the next time one tries to load a non-sandbox-safe plug-in, the dialog window is displayed again. To do so, issue the following command into a terminal window:
    defaults delete

  6. As previously mentioned in point 3, there are still differences when a non-sandbox-safe plug-in is loaded in Garageband X (even with lowered security settings) versus when it is loaded in any other non-sandboxed DAW.
    The main difference that I am interested in (and the sole covered by my experiments) regards filesystem access. Some of these differences have already been mentioned in the rest of this thread.

  7. When File::getSpecialLocation() is used to retrieve any path in the “user” domain (e.g. userDocumentsDirectory or userHomeDirectory), the returned paths are inside the Garageband sandbox (~/Library/Containers/ The plug-in has permissions to create, read and write files in all these folders inside the sandbox.
    Please note that the returned paths are inside the sandbox even if Garageband is in lowered security mode.

  8. On the other hand, using File::getSpecialLocation() to obtain other, non-user paths (e.g. commonApplicationDataDirectory) results in the “real” path being returned, without sandbox interference this time.
    Access to these folders is not limited by the sandbox in any way, but of course the regular filesystem permissions still apply.

  9. Thank to the suggestion made by chkn in this other post, it is possible to write a function that returns the “real” path of the home directory even inside Garageband X. This is the code:

     #include <pwd.h>
     File getRealUserHomeDirectory ()
         struct passwd *pw = getpwuid (getuid ());
         if (pw == nullptr)
             jassertfalse;   // unable to read the user info
             return File::getSpecialLocation (File::userHomeDirectory);
         return File (String (pw->pw_dir));
  10. Using the path returned from that function, my plug-in inside Garageband X had no problems creating, reading and writing files located in the real home directory.
    I admit that this may be due to Garageband being in lower security mode, but since that mode is necessary for my plug-in to be loaded in the first place. Therefore, I can be certain that if my plug-in is running, it can access the real home directory just fine.

In consideration of all these facts, I think I’ll go against the current of those that preferred to move the user files inside “~/Music/Audio Music Apps” for peace of mind.
Instead, I think I will keep them where they have always been, in the user home directory, only changing the way its path is obtained so that the real path is returned even when the plug-in is inside Garageband X.

Unless there is something conceptually wrong that I am missing…


thanks for your detailed post yfede.

Is there somewhere a quick reference about how being sandbox-safe? (and not getting the warning (1) in the first place)

The most promising link that I could find regarding the subject is this:

After quickly skimming through it, though, the work needed for converting our existing plug-in into a sandbox-safe one seemed overkill for the sole goal of making Garageband happy.

However, if somebody is able to “boil down” that document into some practices that can be applied to a JUCE project (cross-platform and cross-format) to make it also sandbox-safe, we are eager to know about that.

1 Like

@jules, in consideration of my post above, what would you think about adding the functionality of that function getRealUserHomeDirectory() to File::getSpecialLocation(), perhaps with an enum label along the lines of realUserHomeDirectory?

That code only compiles on POSIX platforms, but since it is only meaningful on Mac, for the other platforms you could just fall back to returning the same as

File::getSpecialLocation (File::userHomeDirectory)
1 Like

To be honest my understanding is that the best way to be sand-box safe is to support AUv3 and add all the particular rights you need. To the best of my knowledge this is one of the key reasons for AUv3, and once it’s a commonly supported format I suspect Logic and FCP will finally be sandboxed applications (like every other application on the AppStore).

For anyone who wants to build “sandbox-safe” AUs, the .plist file also needs to be updated with the sandboxSafe flag added in the right place.

I’ve made a patch exposing this as an option in the Projucer in the SR branch:

Cheers, Yair

1 Like

Hi @yairadix, just to confirm, there’s more to an AU being sandbox safe than just setting that flag, right? Have you managed to patch JUCE’s AU wrapper code to achieve this, e.g. to use Security-Scope bookmarks for filesystem access etc…?

For filesystem access, if you make sure you only access files under ~/Music/Audio Music Apps, I think it should be good.
I managed to make a plugin that works sandboxed in GarageBand (that is without needing to allow non-sandboxed plugins in GB).

Interesting. That’s not working for me here. If I set the flag in the Info.plist and then do a defaults delete and relaunch GB then GB pops up the warning again when I try to load my plugin. Did you have to do anything else, e.g. entitlements settings?