EDIT 19 October 2026 - I’m not actually sure if a Elastic Defend notification pops up - I can’t find where to re-enable notifications for a system extension!
If you’re running Elastic Defend on macOS and your encrypted external drive mounts for a split second after you enter the passphrase, then disappears, it’s probably not your drive. It’s probably device control.
There is no prompt, no notification and nothing in Disk Utility that tells you why. The volume unlocks, mounts, and is unmounted again in under a second. Here’s how we tracked it down, and what to change.
Troubleshooting
Step 1 - read the Disk Utility log
The Disk Utility log (filtered to the Disk Utility process) shows two things. First, the keychain lookup fails:
libDiskUnlock.dylib [com.apple.diskunlock:Keychain] SecItemCopyMatching failed for <VOLUME_UUID> status = -25300
This is a red herring. -25300 is errSecItemNotFound, which just means the passphrase isn’t saved in your keychain, so macOS prompts you for it.
Second, and more interesting, the volume mounts and then unmounts less than a second later, every time:
10:30:01.400 <SKAPFSDisk: { BSD Name: disk5s1, Mounted: Yes, APFS UUID: <VOLUME_UUID>, Encrypted: Yes }>
10:30:01.776 <SKAPFSDisk: { BSD Name: disk5s1, Mounted: No, APFS UUID: <VOLUME_UUID>, Encrypted: Yes }>
We saw the same pattern five times, with gaps between 0.4s and 0.8s. So the passphrase is accepted and the filesystem mounts fine. Something else is pulling it out from under us, and Disk Utility’s own log can’t tell us what.
Step 2 - find out who unmounts it with eslogger
eslogger (macOS 13+) streams Endpoint Security events, including the process responsible for each mount and unmount. Run this, then unlock the drive:
sudo eslogger mount unmount | jq '{event: .event_type, proc: .process.executable.path, pid: .process.audit_token.pid, path: (.event.mount.statfs.f_mntonname // .event.unmount.statfs.f_mntonname)}'
Output (sanitised):
{
"event": 22,
"proc": "/System/Library/Filesystems/apfs.fs/Contents/Resources/mount_apfs",
"pid": 61904,
"path": "/Volumes/<EXTERNAL_VOLUME>"
}
{
"event": 23,
"proc": "/usr/libexec/diskarbitrationd",
"pid": 584,
"path": "/Volumes/<EXTERNAL_VOLUME>"
}
Event 22 is ES_EVENT_TYPE_NOTIFY_MOUNT and event 23 is ES_EVENT_TYPE_NOTIFY_UNMOUNT. mount_apfs mounts the volume cleanly, then diskarbitrationd unmounts it.
That rules out filesystem corruption. A damaged volume would fail inside mount_apfs or the kernel, not get cleanly removed by the Disk Arbitration daemon. diskarbitrationd doesn’t unmount healthy volumes on a whim; it does it because a policy or a registered Disk Arbitration client asked it to. EDR device control features commonly work this way.
Step 3 - ask diskarbitrationd why
diskarbitrationd logs which client requested the unmount. Unlock the drive again, then:
log show --last 5m --info --debug \
--predicate 'process == "diskarbitrationd" OR subsystem BEGINSWITH "com.apple.DiskArbitration"' \
| grep -iE 'disk5|unmount|client|approval|dissent|policy|not permitted'
It’s also worth unlocking and mounting by hand, because diskutil will often name a dissenting PID that Disk Utility hides:
diskutil apfs unlockVolume disk5s1 -nomount
diskutil verifyVolume disk5s1
diskutil mount disk5s1
From here the trail led to the one Endpoint Security product on the machine: Elastic Defend.
Root cause - Elastic Defend device control
The culprit was the device control setting in our Elastic Defend integration policy. Once we changed the USB storage access level to Allow read, write, and execute, the encrypted drive mounted and stayed mounted.
Device control arrived in Elastic 9.2. It restricts which external USB storage devices can connect to Windows and Mac hosts running Elastic Defend. The launch blog describes three allow levels: read/write/execute, read only, and read/write with execution blocked.
Two details from that blog are worth knowing:
- Device control is on by default for new policies, with the option to block all devices. If you’ve created a Defend policy since 9.2, check it.
- Existing policies got the feature added but turned off, so you may only hit this on newer policies.
Is this documented?
Not really. Elastic’s policy docs cover device control in general and include a table of how access levels map for Windows Portable Devices (phones, cameras). There is no equivalent section for macOS.
Nothing we could find says that, on macOS, a restrictive access level shows up as the volume being silently unmounted straight after mounting. There’s also nothing about encrypted APFS volumes specifically. If you’re a Mac user, the symptom looks exactly like a broken drive.
The fix
The quick fix is to set device control to Allow read, write, and execute in the Elastic Defend policy that covers the Mac. That’s what we did to confirm the cause.
The better fix, if you want to keep device control enforced for everything else, is a trusted device entry. You can scope it by host, device ID, manufacturer or product ID, and apply it to one policy or globally. That lets one known encrypted drive through without opening up USB storage across the fleet.