hdiutil on Mac: convert Over a File Crashed 100 of 150 Runs

I ran hdiutil convert -format UDZO -o out.dmg in.dmg on this Mac mini with an out.dmg already sitting in the folder. The man page says the command should refuse without -ov. It did refuse, in a way: the process was killed with signal 9, exit status 137, and the only text on screen was two progress lines. The kernel log said hdiutil[27352] hit a pac violation. I repeated the same mistake 150 times across five source formats and three target formats. 100 runs ended in that crash. The other 50 printed the documented convert failed - File exists.

hdiutil is the disk image tool that ships with macOS, and I use it more than I expected to. Earlier today I opened document camera installers with hdiutil attach -readonly to read their binaries without running them, and the external SSD format tests ran on sparse images it created. So I spent a session on macOS 26.4.1 timing all 13 image formats it can build, reproducing the errors people search for, and checking what "convert DMG to ISO" actually produces. At the end is a count of the 71 Stack Exchange questions with hdiutil in the title, sorted by what went wrong.

What hdiutil does, and hdiutil vs diskutil

hdiutil works on disk image files: it creates them, converts between formats, verifies checksums, and attaches them. Attaching is the step people skip over. hdiutil attach turns a file into a device node such as /dev/disk4, and only then does macOS mount the volume inside it. diskutil works on devices and volumes, whether they came from a USB drive or an image. That split matters for the most-viewed error below: umount or diskutil unmount removes the volume but leaves the image attached, and a later hdiutil convert or resize on that file fails. If you want to see the attached images that diskutil list mixes in with real disks, I covered that in lsblk on Mac; hdiutil info lists them by image path.

The verbs on this machine, from hdiutil help: attach, detach, eject, verify, create, compact, convert, burn, info, checksum, chpass, erasekeys, imageinfo, isencrypted, makehybrid, mount, mountvol, unmount, plugins, resize, segment, pmap, udifderez and udifrez. The binary is /usr/bin/hdiutil, 732,912 bytes. One caveat for anyone comparing output: this Mac runs in Korean, so hdiutil printed its errors in Korean. They are the standard system error strings, so I've written them below in their English form, with the errno name.

13 formats from the same folder

The test folder was a copy of Slack.app made with ditto: 327 MB on disk, 646 files and folders, 14 of them symlinks. For each format I ran hdiutil create -srcfolder src -format FMT, attached the result with -noverify, recorded the filesystem, and detached it. I did three passes; the chart uses the median.

A few things stood out.

• ULFO beats the default. -srcfolder defaults to UDZO (zlib). ULFO (lzfse, OS X 10.11 and later per the man page) came out 10% smaller, 129.8 MB against 144.5 MB, built a second faster, and was the fastest to read back.
• ULMO is the smallest and the slowest. 99.3 MB, 31% under UDZO, but it took 42.6 s to build against 8.1 s. The man page marks it macOS 10.15 and later, so Macs on older releases can't open it.
• UDBZ and UDCO have no reason to exist on a current Mac. UDBZ (bzip2, which hdiutil convert -help labels deprecated) was bigger than ULMO and slower to read than any other format. UDCO (ADC) took 41.4 s to make a file larger than UDZO's.
• Everything was APFS inside except UNIV, which mounted as HFS+. I didn't pass -fs, so on this release a folder image is APFS by default.
• UDRO ran 17.3 s on the first pass and 5.8 s after, which is the file cache warming up, not the format. The table uses passes two and three for that reason.

Then I copied the volume back out of each compressed image with ditto, a few minutes after building it, so the image file was most likely still in the cache and the number mostly measures decompression:

Format	Compression	Size	Create	Copy out
UDRO	none, read-only	327.6 MB	5.8 s	0.65 s
UDZO	zlib (default)	144.5 MB	8.1 s	0.69 s
ULFO	lzfse	129.8 MB	6.9 s	0.51 s
ULMO	lzma	99.3 MB	42.6 s	2.81 s
UDBZ	bzip2	119.6 MB	25.3 s	5.49 s
UDCO	ADC	157.5 MB	41.4 s	0.67 s

One more thing about those create times: they come in steps. Below ten seconds, every run landed on 2.3, 3.5, 4.6, 5.8, 6.9, 8.1 and 9.2 seconds, about 1.15 s apart. A one-file folder took 4.6 to 5.8 s, and a blank 10 MB APFS image took 1.16 s every time. hdiutil appears to check for completion on a fixed interval, so any difference under about a second in a benchmark like this is noise, and in five tries a one-file DMG never took less than 4.6 s.

For shipping an app, UDZO and ULFO both kept the signature intact: codesign --verify --deep --strict passed on the mounted Slack.app from UDZO, ULFO and UDTO images. That matters for the next section.

Converting a DMG to ISO: what you actually get

Two different commands get suggested for this, and they produce different things.

hdiutil convert in.dmg -format UDTO -o out writes out.cdr, which many guides then tell you to rename to .iso. I checked the bytes. The file is a raw disk: file reports a protective MBR, hdiutil imageinfo shows a GUID partition map, and the APFS volume from the original image is inside it unchanged. There is no ISO 9660 signature at offset 0x8001, where CD001 should be. Renaming it doesn't change that. A Windows or Linux machine that can't read APFS won't read this file either.

hdiutil makehybrid -iso -joliet -o out.iso src builds a real ISO 9660 filesystem from a folder; file reports ISO 9660 CD-ROM filesystem data 'SRC' and the signature is where it belongs. But it isn't a safe container for a Mac app. Mounted back on this Mac, the 14 symlinks inside Slack.app came back as regular files of 35 bytes, each holding the text of its link target, and codesign failed with code object is not signed at all. The man page says -iso includes Rock Ridge extensions, which can carry symlinks; I only tested macOS's own reader, not Linux. Without -iso -joliet, makehybrid makes a hybrid that macOS mounts through its HFS+ side, and codesign failed there too: resource fork, Finder information, or similar detritus not allowed.

So: if the goal is a file another OS can read, use makehybrid. If the goal is distributing a Mac app, stay with UDZO or ULFO and don't convert at all.

The convert crash

Back to the opening. I created a two-byte file named d.dmg, then ran hdiutil convert -quiet -format TGT -o d.dmg SRC ten times for each pair:

Source format	Target UDZO	Target ULFO	Target UDRO
UDRW	10/10 killed	10/10 killed	10/10 killed
UDRO	0/10 killed	0/10 killed	0/10 killed
UDZO	2/10 killed	0/10 killed	10/10 killed
ULFO	10/10 killed	10/10 killed	9/10 killed
UDSP	9/10 killed	10/10 killed	10/10 killed

Every run that wasn't killed exited 1 with convert failed - File exists. The rates moved between batches: an earlier loop that sent output to /dev/null got the clean error 9 times in a row from a UDRW source, and the next batch crashed 39 of 40 times. That pattern points to a race rather than a format rule. With -verbose, the write thread returns 17 (EEXIST), the compression and checksum threads print ABORT trying to dequeue work, and then the process dies. The crash report puts the failure in BLKXConvertWorkElement::~BLKXConvertWorkElement() inside the DiskImages framework, called from _performConversion, with exception EXC_ARM_PAC_FAIL: pointer authentication caught a bad pointer during cleanup and the kernel killed the process.

The good news is that the existing file was never touched. I checked its MD5 before and after the first crash, and the two-byte file still read x after all 150 runs. The bad news is for scripts: exit 137 and no message looks like an out-of-memory kill or an outside kill -9, not a name collision. Each crash also leaves a report in ~/Library/Logs/DiagnosticReports; 26 piled up during these tests before I deleted them. The fix is to pass -ov or delete the target first. hdiutil create onto an existing file did the documented thing every time: exit 1, create failed - File exists.

The errors people search for, reproduced

Each row is a command I ran on purpose to get the message. The errno column is the underlying system error, which is why some messages say nothing about disk images.

Message	What triggered it here	errno
attach failed - image not recognized	a text file named .dmg; the first 1 MB of a valid UDZO image	none (hdiutil's own)
attach failed - Permission denied	image file with mode 000; mode 444 with -readwrite (without the flag it mounts read-only)	EACCES
create failed - No space left on device	-size 10m -srcfolder on the 327 MB folder	ENOSPC
create failed - Operation not permitted	writing the image to /System	EPERM
compact failed - Operation not permitted	compacting a UDZO image	EPERM
compact failed - Function not implemented	compacting a UDRW image, on AC power	ENOSYS
convert failed - Resource temporarily unavailable; resize: failed ... (35)	the image still attached, including after a plain umount	EAGAIN
couldn't unmount "disk5" - Resource busy, exit 16	a shell with its working directory inside the volume	EBUSY
burn failed - Operation not supported by device	no optical drive attached	ENODEV
attach: extra image argument	two paths after attach, which is what an unquoted path with a space becomes	usage error

Three of these deserve a note. compact only works on SPARSE and SPARSEBUNDLE images (the man page says so in its first sentence), and on the wrong format it fails with two different errors depending on the format, neither of which mentions the format. On a sparse image and a sparse bundle it ran fine. The accepted answer on the "Function not implemented" question (14,512 views) blames battery power and suggests -batteryallowed, which is a real flag; this Mac mini has no battery and produced the same message from a non-sparse image, so check the format first.

Resource temporarily unavailable is the single most-viewed hdiutil question, 41,579 views, and the accepted answer is right: the image was unmounted with umount instead of detached. I reproduced it exactly. After umount /Volumes/Bench, hdiutil info still listed the image with its device nodes, and convert failed until I ran hdiutil detach on the device.

Resource busy doesn't tell you who is holding the volume. diskutil unmount does: on the same volume it printed dissented by PID 29660 (/bin/sleep) and the parent shell's PID. hdiutil detach -force ejected it in 0.17 s, out from under the busy shell.

I didn't reproduce "Operation not permitted" from privacy protection, where Terminal reads a folder it lacks access to; that case, and why it sometimes hangs instead of failing, is in Full Disk Access for Mac Terminal.

What 71 Stack Exchange questions ask about

I pulled every question with hdiutil in the title from Stack Overflow, Ask Different, Super User, Server Fault and Unix & Linux through the Stack Exchange API: 71 questions, 251,976 views in total, sorted into groups by title.

Group	Questions	Views
Busy, temporarily unavailable, detach	9	73,910
Mounting and basic usage	12	59,081
Other create, convert or attach errors	22	43,389
compact	4	28,080
Scripting and passwords	17	17,882
Linux and Windows	2	13,983
DMG background and license	2	12,401
ISO, CD and hybrid	3	3,250

35 of the 71 questions, holding 145,379 views (58%), are about an error message. The busy and unavailable group is the biggest by views and the advice in it boils down to one rule: detach images with hdiutil detach, not umount. One question in the errors group, create failed - File exists when the file doesn't exist, happened on an NFS share and was never solved; the asker built the image locally and moved it. I didn't test network shares.

FAQ

What is hdiutil on Mac?

hdiutil is the command-line tool built into macOS for disk image files (.dmg, .sparseimage, .sparsebundle, .cdr). It creates, converts, verifies, compacts and resizes images, and attaches them as devices so their volumes mount. Run hdiutil help for the list of verbs and hdiutil VERB -help for each one's options.

What is the difference between hdiutil and diskutil?

hdiutil manages image files and attaches them as devices; diskutil manages devices and volumes, including ones that came from images. Unmounting an image's volume with diskutil or umount leaves the image attached, which causes "Resource temporarily unavailable" on later hdiutil operations. Use hdiutil detach to release an image fully.

How do I convert a DMG to ISO on Mac?

hdiutil convert with -format UDTO produces a .cdr file that is a raw copy of the disk, usually with an APFS or HFS+ volume inside, not an ISO 9660 filesystem, so renaming it to .iso doesn't make it readable on Windows. For a cross-platform ISO, attach the DMG and run hdiutil makehybrid -iso -joliet -o out.iso on the mounted folder. Symlinks and code signatures may not survive that conversion.

Method: all tests ran on 2026-10-08 between 15:00 and 15:30 KST on a Mac mini M4 (Mac16,10, macOS 26.4.1 build 25E253, /usr/bin/hdiutil 732,912 bytes) in a scratch folder under my work directory. The source folder was a ditto copy of Slack.app, not modified. Times are wall-clock from Perl's Time::HiRes around each command, three passes per format; copy-out times are single runs from a warm cache. The crash counts come from 150 runs on images I created for the test, and the crash details from the macOS crash report and kernel log for those runs; one report is kept with my notes and the rest were deleted. Error messages were printed in Korean on this Mac and are given here as the standard English strings for the same errno. Option descriptions are quoted from the hdiutil(1) man page. The Stack Exchange counts come from the API title search for "hdiutil" on 2026-10-08, grouped by keywords in the title.