DMG background image not visible on old macOS

That seems to work in macOS Tahoe. However, the background image is not visible on earlier versions of macOS.

I've also found that a background image set on a Mac running Monterey is not visible on a Mac running Tahoe.

Is there a way to add a background image which works across multiple macOS versions?

First off, checking for an easy-to-overlook issue, did you copy the "source" image onto the volume you're trying to create?

The Finder ends up directly storing a reference to whatever image you give it, so you need to manually add the image to your volume before you set the background image.

Assuming that's not the issue, then I want to start with a few points to understand as background:

1. The DiskImage itself is largely irrelevant. DiskImages work by "injecting" a virtual block storage device "into" the kernel, which the kernel processes exactly the same way it would handle any other block storage device, which then eventually leads to a new volume. By the time a volume actually appears on the desktop, the system doesn't really distinguish between "normal" volumes and "DiskImage" volumes, so virtually any issue you run into is a general volume issue, not a problem with "DiskImages". It's important to understand this, as it's otherwise too easy to end up wasting time investigating issues at the "wrong" level of the system.

2. The "background image" feature of the Finder is undocumented because it's an incredibly old (I believe it was introduced in MacOS Classic 8.0) user feature that was simply carried into MacOS X and has continued ever since.

That second point is critical here because it's why we've never had any official process or API support for configuring this kind of "installer DMG" window - this is simply something developers did on their own without "official" support from the system. The process from the very beginning has basically been:

• Configure a volume/DiskImage EXACTLY the way you want it to be in every detail.

• (optional) "Cleanup" anything you don't want to actually be on the volume (for example, unnecessary hidden objects like "/.fseventsd").

• Create/convert a read-only disk image from the source volume to "lock in" that state.

...and the Finder then presents it as expected because "that's what it does".

Finally, some suggestions/recommendations that might let you get this working:

• As a "user level" feature, the Finder's primary goal is to make the configuration work on the CURRENT system, not backwards compatibility. For example, it's very likely that the Finder will happily accept image formats that can't ACTUALLY be displayed on every system[1] that an image could theoretically mount. I can't provide any official list of what could/should work, but I'd suggest you start with the "simplest" possible image format and/or simply look at what format a working image is using and copy that.

• I'd strongly recommend using HFS+ as the file system, NOT APFS. It's likely that your DiskImage will be smaller[2] and, more importantly, it's both the format this feature was originally designed for and no longer under active development (unlike APFS), both of which mean it’s less likely to fail unexpectedly.

• Support across other file systems is inconsistent/unpredictable. For example, ISO 9660 and UDF both support background images because both of those formats were both in wide use when CD/DVD distribution was at its "peak". Conversely, I don't think ExFAT/FAT support this because this simply wasn't something that was actually "used". And, yes, it's very likely that there are cases where the Finder will appear to work without actually doing so.

• You may want to consider creating and configuring the initial volume on an older system, which you then modify as needed going forward. The Finder generally avoids unnecessary file system modification, so if you're modifying a "working" read/write master from an older system, then it's likely it will continue working even if there are issues on the current system.

Note that the last point is why bugs in this area tend to be missed/overlooked. At this point, this feature is used almost entirely by developers, particularly when crossing system versions, and existing developers are almost always using it with a read/write "master" volume which was created years ago.

[1] This is an easy bet to make, since this feature is VERY old, and a lot has changed in ~30 years.

[2] HFS+ is somewhat more efficient at storing smaller files and with very small volume sizes.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

UPDATE: Apologies for not replying sooner to the helpful response to my question. Today did a simple test:

• Using Disk Utility, made a simple DMG formatted Mac OS Extended (Journaled).
• Copied a small image file onto the DMG.
• Pressed command-j & clicked on "Picture".
• Dragged a small png image file over where it says "Drag image here".
• Closed and reopened the DMG.
• Background image was properly in place.
• Pressed command-shift-<period>.
• Renamed the image file and added a period to the beginning of its name – clicked on "Use Dot" at the "Are you sure" dialog.
• Closed and reopened the DMG – background image still showing properly.

Then converted the DMG to compressed read only and copied and opened the converted DMG on three other Macs:

• Mac Mini running macOS 15.7.4
• MacBook Air running macOS 12.7.6
• MacBook (Unibody) running OS X 10.11.

The DMG showed the background image correctly on all three older Macs.

So, Kevin's advice to copy the image file to the volume before doing anything else works as does his recommendation to keep the image simple.

Also, this shows that the "Drag image here" function works and that users can easily create hidden files.

UPDATE 2: Have found that the Finder "Show View Options" function will remove a set background image if further changes are made to the window eg. icon size. So, it seems, best approach is to set background image after setting all other window properties.

The DMG showed the background image correctly on all three older Macs.

So, Kevin's advice to copy the image file to the volume before doing anything else works, as does his recommendation to keep the image simple.

Fabulous! I was fairly sure that was the issue, simply because this is an area where very little has changed in... well, quite a while.

Then converted the DMG to compressed read-only and copied and opened the converted DMG on three other Macs:

One small note to future readers/testers. Bookmark resolution relies on identifiers embedded within the volume to uniquely identify volumes. In general, this approach works very well as it allows the volume to be correctly, even when names collide (which is very common), as our volume formatter generates a unique ID for every format run, even if the configuration is otherwise identical.

The problem with disk images is that this ID WON'T be unique, something the system has no good way to account for. So, for example, if you do the following:

1. Create a volume and configure it with one background image.

2. Duplicate the Disk Image.

3. Mount and configure the duplicate with a different image.

4. Unmount all volumes.

5. Remount both images.

...then there's a decent chance you may end up seeing the same image on both volumes, even though both volumes were configured differently. This is a bug in the sense that "in an ideal world this problem would not occur", however, it's also a situation where:

• Most users never see/notice the issue, since it requires specific usage patterns that don't actually happen all that often.

• There isn't really any good fix that would work in the "general" case (meaning, all bookmark resolution).

• The direct alternatives (like relying on simple paths) behave much worse.

...which is why we haven't tried to do "something" about it. However, creating installer DMGs is the one case where you could easily run into it, which I wanted to mention the issue.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware