Can't Eject an External Drive: What's Holding It Open

You finish a copy, click eject, and get told the drive is in use. Nothing you can see is using it. The window is closed, the progress bar is gone, and the drive light may even have stopped blinking. The tempting move is to pull the cable anyway.

That refusal is not the operating system being fussy. It is the last safety check between you and a half-written file system, and it usually points at something specific and findable. This piece covers what eject actually does, why it can be refused, and how to identify the program that is holding the drive before you decide anything drastic.

Eject is a flush, not a formality

When a program saves a file, the data does not necessarily travel to the drive at that moment. Microsoft’s reference for FlushFileBuffers describes the normal arrangement: write calls put data in “an internal buffer that the operating system writes to a disk” on a regular basis, and a flush writes what is buffered out to the device. Buffering makes copies feel instant, and it means “the copy finished” and “the data is on the drive” can be two different moments.

Eject closes that gap. The system finishes pending writes, updates the file system’s bookkeeping, and only then tells you the drive can go. If something still has a file open on the drive, it cannot honestly do that last step, so it declines.

Why Windows sometimes lets you skip it

Windows has two policies for external drives, described on Microsoft’s page about the default removal policy. Quick removal keeps the device ready to pull at any time by not caching writes, at some cost in performance. It has been the default since Windows 10 version 1809. Better performance allows write caching, and Microsoft says plainly that with it you must use Safely Remove Hardware, because pulling the drive otherwise “risk[s] losing data.”

Two consequences follow. First, on a modern Windows machine with default settings, an unplugged drive is less dangerous than it used to be, but only for that machine and only for that drive’s current policy, which is set per device and remembered for the same port. A drive that someone switched to Better performance, or that you plug into a Mac, gets no such protection. Second, Quick removal does not mean nothing is ever open. If a program has a file on the drive open when you pull it, that program can still be left holding a partly written file. For how the file system itself copes with an abrupt removal, see exFAT, NTFS or APFS.

What “in use” actually means

Both operating systems refuse for the same reason: a process has a file or folder open on the drive. Apple’s page on ejecting when an app is using the disk says an app using the disk can block the eject, that a warning may name the app, and that the remedy is to quit it or close the documents that live on the disk. Apple’s storage device guide adds that another user’s session can be the cause too.

The holder is often not the thing you were just using. A folder open in a file manager window counts, and so can a program that read a file from the drive and never let go: a media player, a backup or sync tool, a document you left open in a background window. Because these run without an obvious window, a drive can look idle while being held.

Finding the holder

Work from cheap and safe to more involved. None of these steps write to the drive.

1. Close the obvious. Quit apps that opened files from the drive, close file manager windows showing it, and on a Mac check the app switcher with Command-Tab, as Apple suggests. Retry the eject.
2. Look up open handles on Windows. The built-in Resource Monitor (run resmon) has an Associated Handles pane on its CPU tab, which Scott Hanselman describes as a way to search across all processes for an open file name. Type the drive letter, for example E:\, and the matching processes are the holders. Microsoft’s Sysinternals Handle utility does the same from a command line and requires administrator rights.
3. Look up open files on a Mac. In Terminal, lsof lists open files. Its manual says that given a mounted-on directory name it lists everything open on that file system. So lsof /Volumes/MyDrive, with your drive’s name, prints the command and process ID of each holder. Quit those programs normally.
4. Log out and back in. Apple’s general eject page lists this as the first step when nothing obvious is responsible, since it ends every process in your session. On Windows, signing out does the same job.
5. Shut down, then disconnect. Apple’s next step is to shut the Mac down, disconnect the disk, and start up again. A clean shutdown closes files and flushes buffers on its way out, which makes it the safe form of “just pull it.”

What not to do

Avoid the shortcuts that skip the flush. Force-quitting the process that holds the drive, or telling a tool to close its handle, can leave the file it was writing half done. Handle’s own documentation warns that closing handles “can cause application or system instability.” A forced unmount has the same problem: it discards the check that exists to protect the drive. If an eject fails during a copy or a backup, let the job finish or cancel it from inside the program first.

If you have already pulled a drive and it now misbehaves, do not format it as a first response. Connect it, look at what is there, and copy off anything you need before running a repair. Repair tools can only tidy contradictions in the file system, not restore the write that was cut short, and Apple documents First Aid in Disk Utility as the built-in check.

Making it stop happening

• If ejects fail after every session, run the lsof or handle search once and note the same program appearing each time. That is the one to quit or configure to ignore the drive.
• Treat “in use” as information. It means data may still be moving, so waiting a minute after a large copy is often all it takes.
• For a drive you routinely unplug, leave Windows on Quick removal, and eject anyway. It costs a few seconds and covers the case where a program still has a file open.

The eject refusal is the operating system telling you it cannot yet promise that what you saved is on the drive. Finding the program that is holding it is almost always faster than recovering from ignoring it.

• troubleshooting
• external
• windows
• macos