Hey JUCE world,
I working on a plug-in and trying to save presets to the system /Library directory on macOS. When I try to do this I get a “Permission denied” error, in this case when creating a new preset file in a subdirectory of /Library. Does anyone out there know how to work around this? How to give the plug-in permission to write to this directory?
Thanks!
The convention is to write stuff like that to a sub-directory of ~/Library/Application Support, mostly I guess because stuff like a user preset should not be visible to other users on the system. More recently I’ve seen a trend towards putting presets etc in ~/Music, though personally I dislike that.
At the risk of sounding like a Python Stackoverflow “answer”: why do you want to write to the system Library folder rather than the users?
I agree with @asimilon that a good place for presets would be ~/Library/Application Support/.
However, if you want to make the presets available to all users, then /Library/Application Support/ would be best. (So says the Apple dev support eskimo.) The proper way of doing it, I believe, is to dip into Swift in your c++ code to run some Applescript that runs Shell code with administrator privileges.
The easier way that doesn’t look as good is to call osascript in Juce child process so you don’t have to get into swift.
Apple’s guide on admin privs:
https://developer.apple.com/forums/thread/708765
The “blessed” location for sandbox-safe plugins (which is to say anything that has to work in Logic/Mainstage/Garageband) is ~/Music. A sandboxed plugin can only write to the app’s own sandboxed directory tree and ~/Music. This is the directory you should use for cross-format presets.
Hi. I just ran into this problem when my plugin tried to create the directory:
/Library/Application Support/MYPLUGINVENDORNAME
and my plugin got a permission denied error. I wasn’t sure what to do next. I found this JUCE forum page.
As an experiment, I created the directory myself in the mac Finder, and then re-ran the plugin and it managed to write a file within the directory without any permission errors!
So how does this help at all?!
Well, here’s the thing: When your user runs your installer software, the installer software has to do
stuff to system folders and maybe ask the user for permission and users are used to that. So one
solution to this problem is to create the directory during plugin installation.
The only problem with this approach is that, if the directory somehow gets deleted, the plugin itself
won’t be able to repair the damage. I think this is an unlikely scenario in practice though.
BTW: While writing to ~/Music etc is a good quick fix, I don’t think we should all have to put up with doing that. If your plugin is licenced per computer rather than per user, then you’re gonna want to install it in the system space so that all users can use it. Admittedly, having more than one user on a personal computer nowadays is probably somewhat rare.
Darn it! It sounds as if I’m going to have to write special-case code to cope with Logic. 
I think I’ll try to store my licence file in /Library/… but if that doesn’t work, I’ll go for ~Music as a backup strategy.
~/Library/Application Support/Manufacturer/Product is the most appropriate place for user-specific settings/licenses/presets and won’t require privilege escalation to write, but won’t be accessible to other users. For home users, that’s fine but for enterprise/facilities, it’s annoying to have to reactivate the plugin for every user.
/Library/Application Support/Manufacturer/Product is the place for computer-wide settings, etc. and requires escalating to root in order to write. This is because it is a change that can affect all users of the computer.
The quick and dirty way to make this folder would be to use JUCE child process, osascript and Applescript’s ‘with administrator privileges’. It will show a window which says “osascript wants to make changes to your computer” which looks a little weird but no one reads these things anyway.
Another option which I, as an end user, don’t really like but maybe other people don’t mind is writing to /Users/Shared. If you do this, make sure you set permissions to world-writeable so it truly is shared.
I think your idea of creatitg the folders you need in the installer is good too. The installer runs as root so you can set up what you need to, but you need to change the permissions to world writeable using an installer script while still running as root in order to let your plugin use the folder while the user is running it. Then, as you say, your plugin needs to check the folder exists and is still writeable and ask the user to rerun the installer if necessary.
Phew, I think that covers it.
Until this day I use
~/Music/Audio Music Apps/YourCompanyName
And that has worked well all these years
(except once when an installer from a certain company created the “Audio Music Apps” folder as root without write permissions for normal users)
This goes back to a recommendation from Apple, at least that’s what it says here:
