I’m getting the com.apple.diskmanagement.disenter error -119930868 on my Mac when I try to mount or access an external drive. It was working before, but now Disk Utility won’t open it and I’m worried about losing my files. I need help figuring out what caused this and how to fix it safely.
‘disenter error’ on macOS, what worked for me
I ran into this with an external drive and it was the usual macOS mess. The Mac saw the hardware, but the volume would not mount. In plain terms, the system noticed the disk, then Disk Management refused to finish the job.
What I kept seeing was a stuck fsck process. macOS starts it after a drive gets unplugged the wrong way, or after a messy disconnect. On bigger drives, especially ExFAT and some APFS volumes, it sometimes hangs and keeps the disk busy forever. The drive shows up, but you still can’t open it.
First thing I tried
Open Terminal and run:
sudo pkill -f fsck
You will need your admin password.
What this did for me was stop the file system check process. A couple times, the drive mounted right after. Once it came back read-only, which was fine. I only wanted my files off it.
Disk Utility, but do it in the right order
A lot of people only click First Aid on the grayed-out volume and then wonder why nothing changes. I made that mistake too.
Here’s the better path:
- Open Disk Utility.
- Click View.
- Pick Show All Devices.
- Run First Aid on the top physical disk first.
- Then run it on the container.
- Then run it on the volume itself.
If it fails once, I would still try again. I had one disk clear errors after the third pass. It looked dead at first, then First Aid finally got through whatever was broken in the partition layout.
When First Aid gives up
If Disk Utility throws exit code 8, or says the volume cannot be repaired, I would stop pushing it. Repeated mount attempts on a damaged disk are not a fun gamble if your data matters.
At that point, the safer move is recovery first, repair later.
I used Disk Drill in one case because macOS would not mount the volume at all. It was still able to scan the drive directly and pull up the file tree. That let me copy data to another disk before wiping the bad one. If the catalog or file system index is trashed, tools like this sometimes still read the raw sectors well enough to salvage stuff.
One dumb macOS bug worth trying
I also saw a weird case where nothing fixed the mount issue until I logged out and back in. Safe Mode helped once too. My guess is the DiskManagement service got wedged and restarting the user session shook it loose.
So before you erase anything, I would try:
- logging out of your account, then back in
- booting into Safe Mode
- doing a normal restart
It sounds too simple, I know. Still worked for me once, so I keep it on the list.
What I would do in order
- Run
sudo pkill -f fsck - Check if the disk mounts, even read-only
- In Disk Utility, enable Show All Devices
- Run First Aid from physical disk down to volume
- If First Aid reports exit code 8 or won’t repair, stop
- Recover files to a different drive
- Only then reformat the problem disk
Error -119930868 usually means macOS sees the drive, but refuses the mount because the file system, partition map, or enclosure handshake looks wrong. It is often one of these:
- Bad USB cable, hub, or adapter.
- Corrupted ExFAT, APFS, or HFS+ metadata.
- NTFS drive with flaky third-party NTFS software.
- Power issue on larger external drives.
- Failing drive bridge board, even when the disk itself is still ok.
I slightly disagree with @mikeappsreviewer on one part. Killing fsck is fine if it is clearly hung, but I would not start there if your files matter. If the drive is making clicks, vanishing from System Information, or taking minutes to identify, I would stop mount attempts first and check hardware.
What I’d do next:
- Try a different cable and port, no hub.
- Test on another Mac. If it fails there too, the issue is on the drive side.
- Open System Information, USB or Thunderbolt section, and confirm the enclosure shows up.
- In Terminal, run diskutil list. If the physical disk appears but the volume type looks blank or odd, the file system header is damaged.
- If it is NTFS, remove any old NTFS helper app. Those cause disenter errors a lot.
- If Disk Utility still refuses it, switch to recovery first.
For data safety, Disk Drill is a solid option because it scans drives even when Finder and Disk Utility won’t mount them. If your goal is file rescue before repair, that’s the lane I’d take.
Also, if this is an HFS+ drive, a clearer fix path is: recover data and rebuild the HFS catalog with Disk Drill to resolve the disenter mount error. If you want a visual walkthough, this video on fixing the disenter mount error and rebuilding the HFS catalog covers the process well.
If the disk mounts read-only anywhere, copy your stuff off fast. Do not keep testing it for fun. That’s how pepole turn a repairable disk into a dead one.
That error usually means macOS can see the device, but it does not like something about the volume structure enough to mount it. So this is not always “dead drive = instant doom.” Sometimes it’s the partition map, sometimes the enclosure, sometimes the file system header is just borked.
I mostly agree with @mikeappsreviewer and @jeff, but I would not spend too long trying random mount/repair cycles if the files matter. That can go sideways fast.
A few things I’d check that they didn’t really dig into:
- See if the drive is mounting on another OS. If you have access to a Windows PC and the disk is ExFAT/NTFS, test there. If it opens, stop troubleshooting on the Mac and copy data off first.
- Check SMART status if the enclosure allows it. Apps like DriveDx or
smartctlcan sometimes tell you if the disk is physically failing. If SMART looks bad, don’t keep poking it. - Try the bare drive if it’s in a removable enclosure. I’ve had the USB-SATA bridge fail while the actual disk was fine. Super annyoing, but common.
- Unmount every other external disk first. Sounds silly, but I’ve seen Disk Utility get weird when multiple flaky externals are connected.
If the disk won’t mount but still appears in diskutil list, that’s usually the moment I switch from “repair” to “recover.” For that, Disk Drill is one of the more practical Mac options because it can scan an unmountable external drive directly and let you recover files before reformatting. That’s the safer play if you’re worried about data loss.
For anyone specifically searching around for tools, this is the basic idea: best data recovery software for an unmountable external drive on Mac. Also, this watch how to recover files from an unmountable drive on Mac vid is pretty relevant.
One more thing: if this started right after a macOS update, don’t ignore that. I’ve seen older NTFS helpers and security tools trigger disenter errors after system updates. Remove that stuff before you do anything too wild.
I’d add one angle the others only touched lightly: permission and mount policy issues. I’ve seen com.apple.diskmanagement.disenter error -119930868 happen when the file system itself was mostly fine, but macOS refused the mount because of stale mount points, security software, or a weird /Volumes conflict.
Things I’d check that complement what @jeff, @sternenwanderer, and @mikeappsreviewer already covered:
-
Look for duplicate mount folders
In Terminal:ls /VolumesIf you see old folders with the same drive name, macOS can get weird. Sometimes removing an empty stale folder in
/Volumesfixes the refusal. -
Try a manual read-only mount
This is safer than forcing writes:diskutil info /dev/diskX sudo mkdir /tmp/testmount sudo mount -o rdonly -t exfat /dev/diskXs1 /tmp/testmountSwap
exfatfor the real filesystem if needed. If it mounts read-only, copy data immediately. -
Check for background blockers
Antivirus, “cleaner” apps, NTFS tools, backup agents, and even some encryption utilities can intercept mount events. I slightly disagree with the “just run repairs first” mindset, because if a kernel extension or helper is interfering, repair attempts won’t solve the real issue. -
Inspect logs instead of guessing
Run:log show --last 10m --predicate 'process == 'diskarbitrationd' || process == 'diskmanagementd''This can reveal whether macOS is rejecting the mount due to invalid superblock, unsupported filesystem, bad partition map, or a permissions-related failure.
-
If it is an APFS disk
Sometimes the container is visible, but volumes inside it are not. In that case:diskutil apfs listIf the container looks wrong, don’t keep hammering First Aid over and over.
If your priority is files first, not repair, then Disk Drill is a reasonable next move.
Pros of Disk Drill:
- can scan drives that refuse to mount
- good for pulling files off before reformatting
- simple interface compared with more manual recovery tools
Cons of Disk Drill:
- deep scans can take a long time
- recovery quality depends on how damaged the file system is
- not magic if the hardware is dying hard
So my order would be: check logs, test read-only/manual mount, eliminate software conflicts, then use Disk Drill if the volume still won’t mount but the disk is detected. If the drive starts disconnecting mid-test, stop there and treat it like a hardware problem, not a macOS one.


