Like any file, a disk image can become corrupt or damaged, and like any mountable disk its file systems can also become corrupt or damaged. Although those should be very infrequent, their results can disastrous, and render the contents of that disk image inaccessible. This article suggests some solutions you can try.

In theory, if the problem is in the image’s file systems, you should be able to mount its volumes and run First Aid in Disk Utility to check and repair them. In practice that seldom works out, as macOS usually refuses to mount the image. Unless you have ready access to a recent backup, all you can do then is resort to Terminal’s command line to attempt a recovery.

Gaining access to the contents of a disk image requires two steps to complete: first the image must be attached as a device, then after probing of the file systems it contains, those can be mounted.

Read-only and compressed disk images have a checksum stored, and this is normally verified against the image file data first. If that proves invalid, then macOS will refuse to go any further.

In the past, records of checksum verifications have been stored in extended attributes such as com.apple.diskimages.recentcksum, and sometimes deleting those, or a record of the file systems being checked using fsck in com.apple.diskimages.fsck, can allow the disk image to mount. More recently those appear to have fallen into disuse.

Next you should try to attach the disk image without verification or mounting. This is best done using a command such as
hdiutil attach -nomount -noverify diskImagePath
where diskImagePath is the full path to the disk image file, such as /Users/hoakley/VMs/myImage.dmg

If this succeeds, you’ll be rewarded with a list of the resulting devices, such as
/dev/disk4 GUID_partition_scheme
/dev/disk4s1 EFI
/dev/disk4s2 Apple_APFS
/dev/disk5 EF57347C-0000-11AA-AA11-0030654
/dev/disk5s1 41504653-0000-11AA-AA11-0030654

The first is the disk device disk4, and is followed by its two standard partitions disk4s1 and disk4s2. The latter is its APFS container disk5 with its single APFS volume disk5s1. You can now check and repair the last two of those, such as
fsck_apfs -y /dev/disk5s1
which should return a blow-by-blow account of the results. If the file system is HFS+ you may also be able to use third-party repair tools such as DiskWarrior.

When you’ve completed the required repairs, detach the disk image with a command like
hdiutil detach /dev/disk4

If that fails to make the disk image mountable, some have claimed success by converting the disk image to a different format, using a command like
hdiutil convert diskImagePath -format Uxxx -o outImagePath
where diskImagePath is the original disk image, outImagePath is the new image to be created, and Uxxx is the name of a disk image type, as listed in the Appendix.

If none of these gives access to the contents you require, then it’s almost certain that the only way ahead is to find the latest backup of that disk image, and use a copy of that.

Appendix: Supported disk image formats

• UDRW – UDIF read/write, sparse file from macOS 12
• UDRO – UDIF read-only
• UDCO – UDIF ADC-compressed
• UDZO – UDIF zlib-compressed
• ULFO – UDIF lzfse-compressed (OS X 10.11)
• ULMO – UDIF lzma-compressed (macOS 10.15)
• UDTO – DVD/CD-R master for export
• UDSP – sparse image, grows with content
• UDSB – sparse bundle, grows with content, bundle-backed, Mac OS X 10.5
• UFBI – UDIF entire image with MD5 checksum.
• ASIF – sparse image, grows with content, macOS 15.