A disk with a mount point is required

Fix 'A disk with a mount point is required' on macOS

This error hits when you try to erase, partition, or restore to a disk that macOS can't mount — usually because it's busy, read-only, or has a corrupted partition map. Here's how to actually fix it.

What the error actually means

Disk Utility won't touch a disk it can't mount. That's the whole rule. When you click Erase, Restore, or Partition and see "A disk with a mount point is required," macOS is telling you the volume in question has no active mount point in /Volumes. It's not a permissions thing, and it's not a failing drive (usually). It's macOS refusing to write to a volume it can't read.

What's actually happening here is that Disk Utility calls mount(2) before it does anything destructive, and if that syscall fails — because the volume is busy, read-only, or the filesystem is corrupt — the operation aborts before it starts. The real fix depends on why the mount failed. Three causes account for almost every case.

Cause 1: The volume is busy (something's using it)

This is the most common one by far. You've got a Terminal window cd'd into the drive, or Spotlight is indexing it, or a Time Machine backup is mid-write, or an app has a file handle open. macOS sees the volume as in-use and silently refuses to mount it for Disk Utility's purposes.

I hit this constantly with USB drives I've been rsyncing to. The rsync finished, but the shell is still sitting inside /Volumes/Backup. Disk Utility greys out Erase. You click it anyway. Error.

Fix: force unmount, then retry

Open Terminal and find the disk identifier:

diskutil list

Look for the volume under /dev/disk2 or similar. Then force-unmount the whole disk (not just the slice):

diskutil unmountDisk force /dev/disk2

The reason unmountDisk works where unmount doesn't is that it detaches every slice on the device, not just the one you named. If a process is holding a file open, the force flag kills the mount anyway. Quit Disk Utility, reopen it, and the Erase button will light up.

If force unmount still fails, find the offending process with lsof | grep /Volumes/YourDrive and quit it properly. Nine times out of ten it's Terminal, Preview, or a misbehaving backup agent.

Cause 2: The volume is mounted read-only

Read-only mounts happen for two reasons: the filesystem is dirty (unclean shutdown, yanked USB cable) and macOS auto-remounted it ro, or the drive is physically write-protected (SD card lock switch, or an external enclosure with a RO toggle).

A read-only volume technically has a mount point, but Disk Utility's erase routine still fails, because it can't acquire an exclusive lock. You'll see the same error text, which is why this cause trips people up.

Fix: repair the filesystem, or flip the switch

First, check the physical switch. SanDisk and Samsung external SSDs sometimes ship with a write-protect toggle. Genuinely. Check it.

If it's not physical, the filesystem is dirty. Run First Aid from the Disk Utility toolbar against the volume (not the container or the disk). Disk Utility will run fsck underneath. For APFS volumes on macOS Sonoma or Sequoia, this usually clears the dirty flag in under a minute.

If First Aid says the volume can't be repaired, unmount and run fsck manually from single-user mode or recovery:

sudo fsck_hfs -fy /dev/disk2s1

Swap fsck_hfs for fsck_exfat or fsck_msdos if that's your format. For APFS, there's no standalone fsck — First Aid is the only tool.

Cause 3: Corrupted partition map or a DMG with no mountable filesystem

This is the one that catches people with downloaded .dmg files. You double-click a DMG and Disk Utility throws the mount point error. What's actually happening: the DMG's internal partition scheme is either GPT with no HFS+/APFS volume inside, or the image is truncated from a bad download.

Same story for external drives that were formatted on a Windows box and yanked mid-write. The GUID partition table is there, but the volume header is garbage.

Fix: recreate the partition map

Back up anything you can still read first — you're about to nuke the structure.

In Disk Utility, click View → Show All Devices. Select the parent disk (the one with the manufacturer name, not the indented volume). Click Erase. Choose GUID Partition Map and APFS (or exFAT if you need Windows compatibility).

From Terminal, the equivalent is:

diskutil eraseDisk APFS "NewDrive" /dev/disk2

For a broken DMG, don't try to mount it through Finder. Convert it first:

hdiutil convert broken.dmg -format UDTO -o fixed.cdr

If hdiutil also errors out, the download is corrupt. Re-download it — don't waste time trying to repair a truncated image.

Quick reference

SymptomLikely causeFix
Erase button greyed out, drive visibleVolume busydiskutil unmountDisk force /dev/diskN
Drive mounts but disk is read-onlyDirty filesystem or RO switchFirst Aid, or check physical lock switch
DMG won't open, error on double-clickCorrupt or truncated imagehdiutil convert, or re-download
Foreign drive, weird partitionsBroken partition mapErase parent disk as GUID/APFS
First Aid fails repeatedlyFailing hardwareCheck SMART: diskutil info disk2 | grep SMART

One last thing: if First Aid fails on the same drive three times across a week, stop trusting it. That pattern is hardware, not software, and no amount of fsck fixes a dying platter.

Related Errors in macOS Errors
Stuck in a Google search redirect loop on macOS macOS Big Sur kernel_task high CPU — what really works NSURLErrorDomain error -1012 macOS 'The operation couldn’t be completed. (NSURLErrorDomain error -1012.)' Fix You do not have permission to open the application Fix 'You do not have permission to open the application' on macOS Sequoia

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.