"Disk Not Ejected Properly": What It Actually Means

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

But this one is especially for the beleaguered -- the people who have dismissed that alert not a handful of times, not even dozens of times, but seemingly hundreds. If that sounds like you, you're not alone, and we're going to get to the bottom of what's actually 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 present the content of that storage to the user in the Finder. IOKit, the manager of hardware devices, is the first system service to see the device (via the "kernel_task" process). IOKit will create an internal device tree representing components of the hardware device, each component being vended, or supplied, by some IOKit driver (e.g. IOUSBHostInterface > IOUSBMassStorageInterface > IOUSBMassStorageDriver ... IOBlockStorageDriver > Sabrent ROCKET-XTRM-Q Media (IOMedia) > IOMediaBSDClient). The storage drivers then get the DiskArbitration service involved to handle the logistics of volume mounting. DiskArbitration probes the storage to determine what filesystem is present, then invokes the appropriate filesystem drivers to handle filesystem consistency checking and other volume pre-mount logistics. Once volumes are identified for mounting, DiskArbitration creates a mount point folder (e.g. /Volumes/Backup), mounts the volume, and 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 superficial. When a request is made to unmount a volume, that request is fielded by the DiskArbitration service.

DiskArbitration issues a system-wide notice of the impending unmount, and gives any application that cares the opportunity to "dissent" the unmount request (and blocking the action). If there are no dissenters, the volume is unmounted and the mount point folder is deleted. It stops there, though. All of the underlying device objects remain intact and tracked by the IOKit service. If you're curious to see these "under the covers", run ioreg -w 0 -l in the Terminal and then search for "IOMediaBSDClient". You can also see the top of this device tree in Disk Utility if you select "Show All Devices" from the "View" menu. If you just unmounted a volume, you'll see the unmounted volume and one or 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 ejected, macOS can no longer see it. I need to make a brief grammatical digression here. The "eject" verb is used ambiguously nowadays, and its use has changed over the years as hardware has changed. Originally, "ejecting" storage meant that the storage was physically ejected from the storage device. Think Zip drives and DVDs – when you ask the system to eject the device, that means you want to take the storage out of the storage device and put it somewhere else. In those cases when the physical media was removed from the storage device, that was a true "ejection" – not only does the volume mount get unwound, but all of the supporting IOKit tree objects are also discarded. In contrast, when you "eject" a volume in the Finder, that's not actually ejecting anything, it's only unmounting a volume. Even when Finder offers to "eject" all volumes on a disk when you choose to "eject" one of them, the subsequent action is only unmounting the volumes, nothing happens to the underlying internal device objects.

As far as the "Disk Not Ejected Properly" dialog and this article are concerned, though, we're referring to an ejection in which IOKit has discarded all internal tree objects associated with the storage device and macOS can no longer "see" it.

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

16:19:01    Adding [/dev/disk8] to diskobjects[90] 16:19:01    Adding [/dev/disk8s1] to diskobjects[91] 16:19:01    Adding [/dev/disk8s2] to diskobjects[92] 16:19:01    Adding [/dev/disk9] to diskobjects[94] 16:19:01    Adding [/dev/disk9s1] to diskobjects[95] 🔒 FileVault encrypted. [APFS Test] 16:19:01    Adding [/dev/disk9s2] to diskobjects[96] 16:19:01    [INFO] Volume mounted: "/Volumes/Photos Archive" (/dev/disk9s2)

Now graceful unmounting of that volume:

16:54:30    Not dissenting the volume unmount request for /Volumes/Photos Archive. 16:54:30    [INFO] Volume unmounted: "Photos Archive" (/dev/disk9s2)

Proving the graceful nature of this unmount, we see that CCC received an offer to dissent the unmount request. CCC wasn't using the volume as a source or destination to a backup task, so it did not dissent. The volume was subsequently unmounted, but the underlying storage devices remained within IOKit.

Next, we see what happens when the device is physically detached:

16:56:03    Device removed from IOKit by the macOS kernel: /dev/disk9s2 16:56:03    Device removed from IOKit by the macOS kernel: /dev/disk9s1 16:56:03    Device removed from IOKit by the macOS kernel: /dev/disk9 16:56:03    Device removed from IOKit by the macOS kernel: /dev/disk8s2 16:56:03    Device removed from IOKit by the macOS kernel: /dev/disk8s1 16:56:03    Device removed from IOKit by the macOS kernel: /dev/disk8

Very cleanly, the devices are removed from IOKit (CCC "sees" these events because it subscribes to IOKit for "interest notifications", i.e. "tell me when a state change occurs for this device").

Now I'll revisit the annoying behavior that actually occurred a few minutes prior when I attached this device to my Mac, picking back up where the "Photos Archive" volume was mounted:

16:19:01    [INFO] Volume mounted: "/Volumes/Photos Archive" (/dev/disk9s2)

16:19:06    [INFO] Volume unmounted: "Photos Archive" (/dev/disk9s2) 16:19:06    Device removed from IOKit by the macOS kernel: /dev/disk9s2 16:19:06    Device removed from IOKit by the macOS kernel: /dev/disk9s1 16:19:06    Device removed from IOKit by

the macOS kernel: /dev/disk9 16:19:06    Device removed from IOKit by the macOS kernel: /dev/disk8s2 16:19:06    Device removed from IOKit by the macOS kernel: /dev/disk8s1 16:19:06    Device removed from IOKit by the macOS kernel: /dev/disk8

16:19:09    Adding [/dev/disk8] to diskobjects[90] 16:19:09    Adding [/dev/disk8s1] to diskobjects[91] 16:19:09    Adding [/dev/disk8s2] to diskobjects[92] 16:19:09    Adding [/dev/disk9] to diskobjects[93] 16:19:09    Adding [/dev/disk9s1] to diskobjects[94] 🔒 FileVault encrypted. [APFS Test] 16:19:09    Adding [/dev/disk9s2] to diskobjects[95] 16:19:09    [INFO] Volume mounted: "/Volumes/Photos Archive" (/dev/disk9s2)

Five seconds after the "Photos Archive" volume was mounted, and while I was contemplating whether I should plug in the password for the encrypted volume on that disk, the device popped offline. The key difference between this event and the graceful unmount is that a) there was never a "would you like to dissent this unmount" notification sent from DiskArbitration and b) all of the underlying devices were simultaneously removed from IOKit by the macOS kernel. Three seconds later (and no physical intervention on my part), the devices reappeared and the volume remounted – once the storage device's firmware rebooted, IOKit rediscovered the hardware and repeated the "attached" procedure. Meanwhile, Notification Center informed me that the disk was not ejected properly.

Dismiss, again. 🙄

Who or what is ultimately to blame for this behavior?

The system log entries offer a little bit of insight into the events (actually, system log provides way, way too much, but as far as we're concerned, "a little bit"). Here is a selection of the relevant events (some trimmed for brevity) that ensued when the device popped offline without any physical intervention:

16:19:06 kernel: (IOUSBHostFamily) usb-drd2-port-ss@02200000: AppleUSBHostPort::terminateDevice: destroying 0x2eb9/9211/3000 (Rocket XTRM Q): link change interrupt 16:19:06 kernel: (AppleUSBXHCI) AppleUSBXHCIStreamingEndpoint: AppleUSBXHCIEndpoint::transferEvent: 1-3 no transfer ring claimed event 0x0000000000000000 1b000000 01038001 16:19:06 kernel: (AppleUSBXHCI) AppleUSBXHCIStreamingEndpoint: AppleUSBXHCIEndpoint::transferEvent: 1-4 no transfer ring claimed event 0x0000000000000000 1b000000 01048001 16:19:06 kernel: (AppleUSBXHCI) AppleUSBXHCIStreamingEndpoint: AppleUSBXHCIEndpoint::transferEvent: 1-7 no transfer ring claimed event 0x0000000000000000 1b000000 01078001 16:19:06 kernel: (IOAccessoryManager) IOPortTransportState::handleStateChange(): [Port-USB-C@3: USB2] Handling state change... 16:19:06 usbpowerd: terminated

<private> 16:19:06 kernel: (IOUSBMassStorageDriver) USB device 2EB9921102200000 - Sabrent, Rocket XTRM Q - detected termination of interfaceNub, currentPowerState 1, provider is IOUSBMassStorageInterfaceNub

16:19:06 kernel: (apfs) dangling_mount_callback:4689: Found dangling mount /dev/disk9s2 16:19:06 kernel: (apfs) container_get_dangling_mounts:4713: Found 1 dangling mounts on /dev/disk9 16:19:06 kernel: (apfs) apfs_log_op_with_proc:3297: disk9s2 unmounting volume Photos Archive, requested by: kernel_task (pid 0); parent: kernel_task (pid 0) 16:19:06 kernel: (IOStorageFamily) disk9: media is not present. 16:19:06 kernel: (IOStorageFamily) disk9: media is not present. 16:19:06 kernel: (IOStorageFamily) disk9: media is not present. 16:19:06 kernel: (apfs) tx_flush:1194: disk9 xid 3893 sync/barrier failed: 6 16:19:06 kernel: (apfs) apfs_vfsop_unmount:3416: disk9s2 failed to finish all transactions before unmount! (err 6) 16:19:06 kernel: (IOUSBMassStorageDriver) IOUSBMassStorageDriver: 2EB9921102200000 stop ...

16:19:06 storagekitd: [com.apple.storagekit:general] -[SKDaemonManager(DiskNotifications) addDisappearedDisk:]: <SKDisk: [566] { BSD Name: disk8,