"Disk Not Ejected Properly": What It Actually Means - Bombich Software

Blog Home

"Disk Not Ejected Properly" 😡: what that macOS alert really means

Mike Bombich July 7, 2026

From the Help Desk

For many macOS users, myself included, this phrase can be triggering. Maybe<br>you've bumped into it once or twice after errantly detaching a disk without<br>unmounting it first -- if that's you: you'll find the short<br>version in the what to try<br>section below, and the rest of the article explains the "why" if you're<br>curious.

But this one is especially for the beleaguered -- the people who have<br>dismissed that alert not a handful of times, not even dozens of times, but<br>seemingly hundreds. If that sounds like you, you're not<br>alone , and we're going to get to the bottom of what's actually<br>going on.

How does a disk actually get mounted in the first place?

When a storage device is attached to a Mac, several services collaborate to<br>present the content of that storage to the user in the Finder.<br>IOKit , the manager of hardware devices, is the first system<br>service to see the device (via the "kernel_task" process). IOKit will create<br>an internal device tree representing components of the hardware device, each<br>component being vended, or supplied, by some IOKit driver (e.g.<br>IOUSBHostInterface ><br>IOUSBMassStorageInterface ><br>IOUSBMassStorageDriver ...<br>IOBlockStorageDriver ><br>Sabrent ROCKET-XTRM-Q Media (IOMedia) ><br>IOMediaBSDClient). The storage drivers then get the<br>DiskArbitration service involved to handle the logistics of<br>volume mounting. DiskArbitration probes the storage to determine what<br>filesystem is present, then invokes the appropriate filesystem drivers to<br>handle filesystem consistency checking and other volume pre-mount logistics.<br>Once volumes are identified for mounting, DiskArbitration creates a mount<br>point folder (e.g. /Volumes/Backup), mounts the volume, and<br>voila, you can access the content of that volume in the Finder.

What happens when you unmount a volume the polite way?

In contrast to mounting, graceful volume unmounting is actually very<br>superficial. When a request is made to unmount a volume, that request is<br>fielded by the DiskArbitration service. DiskArbitration issues a system-wide<br>notice of the impending unmount, and gives any application that cares the<br>opportunity to "dissent" the unmount request (and blocking the action). If<br>there are no dissenters, the volume is unmounted and the mount point folder<br>is deleted. It stops there, though. All of the underlying device objects<br>remain intact and tracked by the IOKit service. If you're curious to see<br>these "under the covers", run ioreg -w 0 -l in the Terminal and<br>then search for "IOMediaBSDClient". You can also see the top of this device<br>tree in Disk Utility if you select "Show All Devices" from the "View" menu.<br>If you just unmounted a volume, you'll see the unmounted volume and one or<br>two "parent" devices in the sidebar.

So what's the difference between "ejecting" and just unmounting?

Disk ejection is the comparable opposite to attachment; once the storage is<br>ejected, macOS can no longer see it. I need to make a brief grammatical<br>digression here. The "eject" verb is used ambiguously nowadays, and its use<br>has changed over the years as hardware has changed. Originally, "ejecting"<br>storage meant that the storage was physically ejected from the<br>storage device. Think Zip drives and DVDs – when you ask the system to eject<br>the device, that means you want to take the storage out of the storage<br>device and put it somewhere else. In those cases when the physical media was<br>removed from the storage device, that was a true "ejection" – not only does<br>the volume mount get unwound, but all of the supporting IOKit tree objects<br>are also discarded. In contrast, when you "eject" a volume in the Finder,<br>that's not actually ejecting anything, it's only unmounting a volume. Even<br>when Finder offers to "eject" all volumes on a disk when you choose to<br>"eject" one of them, the subsequent action is only unmounting the volumes,<br>nothing happens to the underlying internal device objects. As far as the<br>"Disk Not Ejected Properly" dialog and this article are concerned, though,<br>we're referring to an ejection in which IOKit has discarded all internal<br>tree objects associated with the storage device and macOS can no longer<br>"see" it.

Storage – in particular, tracking the coming and going of the storage – is<br>important to CCC, so we log these events for context. These log entries will<br>help illustrate the differences between device appearance and disappearance,<br>as well as graceful and ungraceful volume unmount, and device ejection.<br>First, the normal appearance of a storage device:

16:19:01 Adding [/dev/disk8] to diskobjects[90]<br>16:19:01 Adding [/dev/disk8s1] to diskobjects[91]<br>16:19:01 Adding [/dev/disk8s2] to diskobjects[92]<br>16:19:01 Adding [/dev/disk9] to diskobjects[94]<br>16:19:01 Adding [/dev/disk9s1] to diskobjects[95] 🔒 FileVault encrypted. [APFS Test]<br>16:19:01 Adding [/dev/disk9s2] to...