diskutil eject: How to Eject Drives From Mac Terminal

Finder tells you the drive is in use. It doesn’t tell you what’s using it or what to do about it. Terminal does both.

Quick answer: Run diskutil eject /Volumes/YourDriveName to eject a drive from Terminal. If it fails, use sudo lsof /Volumes/YourDriveName to inspect open holders. Save your work, let copies and backups finish, quit recognized apps normally, then retry. A process list does not certify that force unmounting is safe.

If you’re comfortable with the command line, Terminal is the most powerful way to handle stubborn drive ejections on macOS. And if you’re not comfortable with it yet, these commands are a good place to start.

Basic ejection with diskutil eject

The most direct way to eject an external drive from Mac Terminal:

diskutil eject /Volumes/YourDriveName

Replace YourDriveName with your drive’s actual name, exactly as it appears in Finder. If the name has spaces, wrap it in quotes:

diskutil eject "/Volumes/My Drive"

This does the same thing as clicking the eject button in Finder. If it works, the drive unmounts cleanly and you’re done. If it fails, you get a more informative error message than Finder ever provides.

You can also unmount without ejecting (the drive stays visible in Disk Utility but isn’t mounted):

diskutil unmount /Volumes/YourDriveName

The difference matters for multi-partition drives. unmount removes one volume. eject removes the physical device and all its volumes at once.

Finding your drive’s identifier with diskutil list

Before using more advanced commands, you need your drive’s identifier. List all connected disks:

diskutil list

The output shows every disk and its partitions. Your external drive will be something like disk4 or disk5. Internal drives are usually disk0 and disk1.

For a more readable overview of just external drives:

diskutil list external

Once you know the disk identifier, you can also eject using the /dev/ path instead of the volume name:

diskutil eject /dev/disk4

This is useful when the volume name contains unusual characters or when the volume isn’t mounted but the disk is still attached.

How to eject all external drives at once

If you need to eject every external drive in one command, there are two approaches.

Using diskutil to find and eject all external disks:

diskutil list external | grep -o 'disk[0-9]*$' | while read disk; do diskutil eject "/dev/$disk"; done

Or using AppleScript from Terminal, which mirrors what Finder does:

osascript -e 'tell application "Finder" to eject (every disk whose ejectable is true)'

The AppleScript approach only ejects disks Finder considers ejectable. It skips your startup disk and network volumes, which is usually what you want.

Force unmounting when diskutil eject fails

Force unmount is a last resort that can lose data or leave files inconsistent. Save your work, finish transfers and backups, and try normal ejection first. If the activity is unclear, wait or shut down fully. The command for one volume is:

diskutil unmount force /Volumes/YourDriveName

Or unmount all volumes on a specific disk at once:

diskutil unmountDisk force /dev/disk4

Force unmount attempts to release the volume despite open holders. It can fail and does not guarantee that app data or pending writes are preserved.

Confirm the exact device with diskutil info before any device-level command. A process name, FD mode, activity light, or fixed waiting period cannot prove the absence of pending writes. Read the risks of force eject before considering it.

Finding what’s blocking ejection with lsof

This is the command that makes Terminal invaluable for ejection problems:

lsof /Volumes/YourDriveName

lsof stands for “list open files.” It shows every process that has a file open on that volume: the process name, process ID (PID), the user running it, and which file is open. (For a focused walkthrough of lsof flags and patterns, see our lsof command guide for Mac users.)

If expected holders are missing, sudo may expose more information:

sudo lsof /Volumes/YourDriveName

Permissions, macOS privacy controls, and timing can limit results even with sudo. An empty list does not certify that the drive is safe to force unmount.

Reading the lsof output

The output looks something like this:

COMMAND   PID   USER   FD   TYPE   DEVICE   SIZE/OFF   NODE   NAME
mds       123   root   12r  REG    1,8      4096       789    /Volumes/MyDrive/.Spotlight-V100/...
Finder    456   aaron  15r  DIR    1,8      1024       2      /Volumes/MyDrive
Dropbox   789   aaron  8u   REG    1,8      8192       345    /Volumes/MyDrive/Projects/.dropbox

The columns that matter most:

• COMMAND: The process name. This tells you what’s blocking ejection.
• PID: The process ID. You’ll use this to kill the process if needed.
• FD: File descriptor and access mode. r means opened for reading, w means opened for writing, and u means read/write access. These are access modes, not proof of current I/O. A read handle does not rule out other or pending writes.
• NAME: The specific file being accessed. This often reveals exactly why the process is there.

Common culprits: mds (Spotlight indexing), backupd (Time Machine), Dropbox, Google Drive, Finder itself. See our deep-dives on Spotlight blocking ejection and iCloud/Dropbox preventing ejection for targeted fixes.

Killing blocking processes

Save your work and use a recognized app’s Quit command first. For a process you own and understand, you can send a termination signal to its current PID:

kill 789

This sends SIGTERM, which the process may handle or ignore. It is not the same as an app’s Quit command and does not guarantee a save prompt. Check that it exits, then retry normal ejection.

If it doesn’t respond to a graceful kill:

kill -9 789

This forces immediate termination. The process doesn’t get to clean up. It can lose unsaved work and interrupt writes. Limit this last resort to a recognized app you have assessed; do not kill Spotlight, Time Machine, or unfamiliar system services.

Avoid piping the whole holder list into kill. That can interrupt apps and system services without giving you a chance to save work or assess each process.

Complete troubleshooting workflow

Here’s the full sequence for a drive that won’t eject:

# Step 1: Try normal eject
diskutil eject /Volumes/YourDriveName

# Step 2: If that fails, see what's blocking
sudo lsof /Volumes/YourDriveName

# Step 3: Save work, finish tasks, and quit recognized apps normally

# Step 4: Try ejecting again
diskutil eject /Volumes/YourDriveName

# Step 5: If still stuck and activity is unclear, shut down fully
# Disconnect only after shutdown completes

Identifying the holder helps you choose which app or task to check. It does not guarantee that quitting one process will resolve the problem.

Useful diagnostic variations

Check if Spotlight specifically is holding your drive:

lsof /Volumes/YourDriveName | grep mds

List only the unique process names blocking ejection (no duplicate lines):

lsof /Volumes/YourDriveName | awk '{print $1}' | sort -u

Watch real-time disk I/O to see if something is actively writing:

sudo fs_usage -f diskio | grep YourDriveName

This runs continuously; press Control-C to stop. A filtered trace can miss activity and does not prove the absence of pending writes. Use it as an additional diagnostic, not permission to force eject.

When Terminal is more work than it’s worth

These commands are powerful, and once you’ve used them a few times, they become second nature. But if you hit this problem regularly, running lsof, reading the output, and deciding which PID is safe to kill gets old.

Ejecta brings detected holders into the menu bar with free diagnosis. Paid actions can quit supported apps and retry ejection. It does not certify the absence of writes or ordinarily terminate system holders such as Spotlight. If you only fight a stuck drive once in a while, the Terminal commands above are all you need. If it happens every week, that’s what Ejecta is for.