.dmg with symlinks to /Library/Audio/Plug-Ins/

Has anyone ever seen a plugin company distribute plugins via .dmg that has symlinks to /Library/Audio/Plug-Ins/Components where dragging into the folder actually works?

I’ve tried every trick in the book (different dmg formats, different tools, named/unnamed symlinks, permissions, signed/unsigned, DS_Store present/removed), but on a machine that didn’t make the dmg, symlinks won’t let you drop files into them.


It works if you created the dmg and it works to double click to open the folders. It also works magically for /Applications but I don’t see any extended attributes or other trick that the OS might be using…

Note that ~/Library isn’t an option, as the ~ is resolved at the time the symlink is made so it would be a symlink to /Users/sudara.

I thought dmg would be a nice n’ easy distribution route on macOS (almost preferable to a heavier duty installer) but this degrades the UX… The workaround would be to have the background image specify “Step 1: Double click folder to open, Step 2: drag plugin into opened window (not the folder icon)” :cry:

There has to be a reason it works with /Applications but not with /Library/Audio/Plug-Ins/*

if anyone can get it working, I’ll gift them a plugin of their choice or lots of their favorite beer :slight_smile: . Example dmg with the issue is here: Make /Library/Audio folders writable · sudara/pamplejuce@8765dc4 · GitHub

I think this technique is being deprecated by Apple (because: sandbox) and the preferred method to do the installs from now on is with a .pkg-type installer. From what I can gather, Apple want to move away from .dmg installers …

But, besides that - when you create the link, are you using the ‘-s’ option, to ensure that a ‘symbolic link’ is made - otherwise it’ll make a hard link, which won’t work (because everyones’ inodes differ)?


$ cd /Volumes/MyNewDiskImage && ln -s /Library/Audio/Plug-Ins/Components  ./Components
1 Like

Yup! Neither symbolic links nor macOS aliases created from finder (which can differ) nor “relative symlinks” (which is something osxtools can create, linking to ~/Library) worked. Apple definitely wants everyone on the App store, but .dmg seems alive and supported (the shiny new notarytool supports it, etc). My theory is it’s just a niche issue and only /Applications has some exception in the actual Finder code. I used an Apple developer support incident on it, I’ll report back if they say anything interesting.

1 Like

What leads you to that conclusion? I’m very much under the impression it’s the other way around! My impression is that Apple don’t like pkg style installers because they can run arbitrary scripts normally with admin privileges however, for the time being they have little choice but to support them.

I think what they would prefer is that things are installed via the AppStore, and apps themselves set up everything required when first launched. As I understand it with the latest drivers for example (which are now all user space), they are designed to be installed by an app on first launch.

1 Like

Okay, this worked for me - @sudara, perhaps you’re not creating a HFS+ image?

$  ls -l TestContents
total 8
lrwxr-xr-x  1 aa_jv  staff  34 Jul 11 15:15 Components -> /Library/Audio/Plug-Ins/Components
-rw-r--r--  1 aa_jv  staff  52 Jul 11 15:15 readme.txt
$ hdiutil create testImage.dmg -ov -volname "TestImage" -fs HFS+ -srcfolder "./TestContents"
$ open testImage.dmg
$ ls -l /Volumes/TestImage/Components/
total 0
drwxr-xr-x  3 root  wheel  96 Sep  8  2020 Analog Lab 4.component
drwxr-xr-x  3 root  wheel  96 Jan 28 20:59 Analog Lab V.component
drwxr-xr-x  3 root  wheel  96 Feb 22 20:24 Chorus JUN-6.component
drwxr-xr-x  3 root  wheel  96 Feb 22 20:47 Comp FET-76.component
drwxr-xr-x  3 root  wheel  96 Feb 23 13:18 Delay TAPE-201.component
drwxr-xr-x  3 root  wheel  96 Feb 22 21:02 Filter MINI.component
drwxr-xr-x  3 root  wheel  96 Feb 23 11:53 Phaser BI-TRON.component
drwxr-xr-x  3 root  wheel  96 Jan 27 21:15 Pigments.component
drwxr-xr-x  3 root  wheel  96 Nov 23  2020 PolarDesigner.component
drwxr-xr-x  3 root  wheel  96 Feb 22 21:17 Pre 1973.component
drwxr-xr-x  3 root  wheel  96 Feb 22 21:19 Pre TridA.component
drwxr-xr-x  3 root  wheel  96 Feb 22 21:36 Pre V76.component
drwxr-xr-x  3 root  wheel  96 Feb 22 20:05 Rev PLATE-140.component

… transferred testImage.dmg to another Mac, different user, confirmed that I was able to access the /Library/Audio/Plug-Ins/Components subdirectory using a simple double-click, could put files in there easily (once authenticated) … (EDIT: no, I didn’t accidentally bundle the .component files into the .dmg volume, before you ask - the only thing the testImage.dmg volume contained was the symbolic link to the directory…)


What leads you to that conclusion?

… I concur with your assessment: Apple want Apps themselves to do the bundling/installing … the old .dmg method is not going away, but I think - with the changes to AUV3 - Apple are definitely signalling that they want .app bundles to be the solution for everything … could be wrong, just imho.

1 Like

Hey, I really appreciate you trying to reproduce this, Jay! Awesome.

It’s drag-n-drop to the dmg symlink that I can’t get to work (see the gif in the OP) — it works to double click the symlink to open the folder and drop in.

Hmm. Drag and Drop works for me. I do have to authenticate to complete the operation, but this is expected behaviour for a non-admin user, no?

BTW I’m automating this myself at the moment so my interest is not entirely selfless. :slight_smile:

Drag and drop (to the symlink icon in the dmg, not the double-clicked-and-opened-folder) on the computer that didn’t create the dmg? If that’s the case would you mind sending me the dmg so I can inspect it? It’s true, I never explicitly tried -fs HFS+, I’ll give that a whirl.

Yes. Sending it to you off-line … check email.

It looks like appdmg (a wrapper for hdiutil) is already specifying HFS+, so I’ve been using that all along.

BUT you found something interesting — when a component from outside the dmg is dragged to the symlink it works and I get the authentication popup!

But when the component is inside the dmg, still no luck…

This gives me a lead though, as I’ve been obsessing over the symlink and looks like it’s never been the issue.

I tested this by dragging the readme.txt file that I included in the .dmg Volume, directly onto the Folder symlink named “Components”, so I don’t think that’s quite an accurate assessment, yet …

BTW, ‘man hdiutil’ is your friend - seems it might be related to the filesystem type of your test machine:

     Some filesystems support permissions including users and groups.  While important for security on a managed filesystem, users and groups ("owners") pose challenges for unmanaged, shared filesystems such as
     those typically present in disk images.  macOS's solution to this problem is to make owners optional, both while creating files and enforcing permissions.

     By default, unknown HFS+ filesystems on "external" devices (including disk images) mount with their owners ignored (mount -o noowners).  Normally when owners are ignored, the system uses a special _unknown
     user and group to dynamically substitute the current user's identity for any owners recorded in the filesystem.  These _unknown owners are even written to the volume when creating new files.  The new files
     will continue to have "floating" ownership when mounted with owners honored.  The net result is that shared volumes behave as expected regardless of how they are accessed.

     The behavior is different when disk images are attached.  With disk images, the owner of all files in a filesystem mount for which owners are ignored is the user attaching the disk image.  The attaching owner
     is also used when creating new files.

     On modern macOS systems, root (UID 0) can "see through" the "owners ignored" user mappings.  Thus
           sudo ls -l /Volumes/imageVol
     will show whatever is really stored in the filesystem (possibly _unknown) regardless of whether owners are currently being honored on that volume.  In contrast, non-root users will see themselves any time
     _unknown is in effect, whether the default for the mount when owners are ignored or because _unknown is stored on disk.  For disk images, non-root users will see owners matching the user that attached the disk

     Unlike owners, permissions are never optional.  A non-writable file will not be writable just because owners are ignored.  However, a file that is writable by its owner will be writable by everyone if _unknown
     is the effective owner of the file for that file.  Because anyone accessing an owners-ignored file is treated as the owner, everyone is effectively the owner.  Because the default behavior for disk image
     filesystems is for all files to be owned by the user attaching the disk image, other users will be treated per the 'group' (if applicable) and 'other' permission modes.

     diskutil(8)'s enableOwnership or the Finder's Get Info window can be used to configure a system to respect the on-disk owners for a filesystem in the future.

testImage.zip (3.3 KB)

Ok, I can confirm the readme.txt can’t drop onto the components symlink.

I’m on an M1 macOS 12.4 Monterey and have had this behavior confirmed by a beta tester on M1 macOS 12 as well as an old mbp 2015 on the same.

Okay - a weird finding. If I DOWNLOAD the .dmg file, somehow MacOS notices and doesn’t let me drag the included readme.txt file into the Components symlink - reproducing your circumstances.

If I merely copy the .dmg file (USB Stick) to another Mac - i.e. it was not Downloaded, rather just copied with the Finder - then I can copy the readme.txt file into the Components symlink.

Try this - make your own .dmg with the commands listed above, then try the test. Then, use the one I attached to this forum (download it) and notice the difference.

The plot thickens …

Its the quarantine bit:

/dev/disk4s1 on /Volumes/TestImage (hfs, local, nodev, nosuid, read-only, noowners, mounted by aa_jv)
/dev/disk5s1 on /Volumes/TestImage 1 (hfs, local, nodev, nosuid, read-only, noowners, quarantine, mounted by aa_jv)

“TestImage 1” is the Downloaded .dmg, “TestImage” is the one I created.

So, quarantine bit … how to disable …

xattr -d com.apple.quarantine testImage.dmg

… works.

But, how to do this for all users?

Yeah, I chased down the quarantine stuff a bit already (been at this for a day or so). The macOS dmg here is notarized but still fails. I’ve tried explicitly signing the dmg (which shouldn’t be necessary) and different combos of code signing and notarization.

The last thing I was investigating yesterday was the more obscure extended attributes I was seeing, such as com.apple.macl stuff — something something registering user intent.

(Following up with more info as I find it …)

Okay, seems like the .dmg files have to be blessed (EDIT: Scratch that, seems like they need to be in UDZO format):


Also tried this and the RW formats…

Here’s a testImageUDZO to test as a Downloaded .dmg file:

testImageUDZO.zip (5.5 KB)