Plug-in can't access external resource files on OSX

MacOSX and iOS
1

Hello devs,

we’ve recently got a pair of tickets regarding an issue happening on the latest OSX (10.15) with both Logic X and Pro Tools, which seems to be related to sandboxing in one way or another (at least I think).

The plug-in is automatically loading external data (static content) which gets installed into:

~/Documents/Company name/static data folder/

to overcome potential sandbox issues, the same content is also being installed into the GarageBand and Logic X sandbox folders:

~/Library/Containers/com.apple.garageband10/Data/Documents/Company name/static data folder/
~/Library/Containers/com.apple.logic10/Data/Documents/Company name/static data folder/

This works for the vast majority of our users, but recently 2 users have reported the same issue with Logic X and Pro Tools: the plug-in loads up, but the static content is not getting loaded at all (for example we have a menu with a list of preset packs which is empty for those users).

In both cases, everything works fine in the standalone version, the data is found and loaded correctly, so the problem only seems to affect the plug-in versions.

Additionally, the plug-in has a preset management system that allows the user to create new preset banks that get stored into the drive.
We asked the users to create a new bank and the file is being created correctly in the right folder under the user Documents:
~/Documents/Company name/banks folder/

so this seems like some kind of read/access permission issue (sandbox? why?)

Both the plug-in and the content installers are notarized, obviously.

We’ve never been able to replicate the issue on our test machines, same versions of OSX and Logic X or Pro Tools, everything works fine.

Any suggestion? Is there any system configuration that may be causing the issue?
What’s the best/fastest route to get Apple support on this? I’ve never contacted them before.

Regards,
Federico

2

Have you had the users check that the files are actually in that location? A permissions issue could have prevented installing them in the first place. In some cases (such as .vstpreset files), we’ve had to include data like this in the plugin’s resources or code, and write them to the user location when the plugin launches (if they are not there already).

3

Of course they are in the correct location, in fact the standalone version is finding them and working perfectly, the problem only occurs in the plug-ins, so there must be a layer in between that is preventing the access to those files, but I have no idea what it is (DAW? Sandbox? Something else?).

We have a lot of users running the plug-in on Catalina in both Pro Tools and Logic X with zero issues, so it’s not DAW specific.

4

I don’t know why you have to get defensive and say “of course” like that. I have no way of knowing that the install in those specific cases succeeded. You don’t want suggestions, fine, I’ll go away.

2 Likes
5

Oh c’mon, that wasn’t intended as defensive or anything like that :smiley:
I wrote “of course” because it was obviously the first thing we checked when we got the report and also because, as I stated in the first post, the standalone is finding the files.
Don’t get me wrong, I appreciate your help, but unfortunately is not as simple as that.

6

But it comes across at best as slightly passive/aggressive and worst as completely douchey. Replace “Of course” with “Yes we confirmed” and you have almost exactly the same information conveyed in a more pleasant manner. Us programmers need to better understand communication with other meat bags isn’t as terse as with silicon.

7

It was intended as a “yes”, I apologise if it came out differently, it surely wasn’t my intention. English is not my main language, so I may have used the term improperly in the context.

3 Likes
8

I think it would be beneficial to double check which path is being accessed for those data files by the plug-in showing the issue (is it the one in the user Documents, or one of those installed in the sandbox?), and compare it with what happens in a copy of the same plug-in that doesn’t exhibit the issue.

And also compare the permission and ownership of those data files being accessed, with those of the file that has been created when the user created the bank (I assume it has been done using the plug-in, i.e. in the same “sandboxed” condition where the loading of the data files fails)

9

Hello Federico, it’s been a while, thanks for chiming in!

I think it would be beneficial to double check which path is being accessed for those data files by the plug-in showing the issue (is it the one in the user Documents, or one of those installed in the sandbox?), and compare it with what happens in a copy of the same plug-in that doesn’t exhibit the issue.

Yeah, the problem is that we’re unable to replicate the issue, so the only solution for now would be to send them a version with some debugging log enabled to check what the paths look like on their machine.
What is puzzling is that the preset banks we’ve asked them to create are correctly being stored into the expected folder inside their Documents folder, not in a sandbox path, so the accesses and permissions seem fine, at least for the folders, maybe the problem is in the files permission?

And also compare the permission and ownership of those data files being accessed, with those of the file that has been created when the user created the bank (I assume it has been done using the plug-in, i.e. in the same “sandboxed” condition where the loading of the data files fails)

I’ve already asked the support to retrieve the permission and ownership information from those users and I’m waiting to get them and have a look.
Good point regarding comparing them with the bank file that’s being created.

Regarding ownership, the installer is built with a postinstall script which does this:

chown -R $USER ~/Documents/blahblahblah

but another dev pointed out to also explicitly add the “staff” group to the owners. On my machine the “staff” permission is being added automatically, I’ll check what happens for those users as soon as I get the related info from the support.

1 Like
10

Is this done also on the copies installed in the sandboxed paths?

11

Yes it is, but I only handled the GarageBand and Logic X sandbox folders, I’m not aware of a Pro Tools sandbox, and yet the problem appears in Pro Tools as well.
I must admit I’m far from being a sandbox expert, so I may be missing some details in this regard.

It’s an extremely rare bug, we only got 1 report from a Pro Tools users and I think around 4 for Logic X users and we have thousands of OSX users.
The software is 6 months old now and the installer script has never been changed.

12

Old post so I’m not sure if you already solved this, but it sounds to me like you’ve run afoul of the Apple-specific macOS permissions system that sits on top of the standard linux permissions. When someone is first using Logic or Pro Tools, they’ll get a popup that says something like “Pro Tools wants access to your Documents folder. Allow?” If they click no, then the folder will forever look empty to that application (and any plugins it loads).

If that’s what happened, the easiest way to check is System Preferences → Security & Privacy → “Privacy” tab → “Files and Folders” from the menu on the left → Find the DAW in question in the menu on the right. Under the DAW, there will be a few checkboxes–make sure they’re checked to let the app access those locations.

2 Likes
13

Thanks for checking in and yes, that’s what the problem was according to our support team. The strange thing is that no alert ever appeared to the users, so we had them manually checking the Security Settings and grant permissions for the DAW to access these folders and that fixed the problem.
Appreciate your post anyway.