Getting files back

The file that will not be deleted

Updated 2026-08-08 · 4 min read

macOS is telling the truth: some process has the file open. The error's failure is not saying which one. The lsof command answers in a second, and the answer is usually one of four things.

Ask which process, do not guess

lsof /path/to/stubborn-file

The output names every process holding the file. That is the whole diagnosis. Quit the named app and the deletion proceeds.

The four usual suspects

1. A mounted disk image — trying to delete a DMG whose volume is still

mounted. Eject the volume in Finder's sidebar first.

1. Quick Look — a preview generated for the file can hold it briefly. Close

preview windows; select a different file.

1. A cloud sync client — Dropbox, OneDrive or iCloud mid-upload on the file.

Pause syncing, delete, resume.

1. The app that made it — an editor with the document open, sometimes as a

background tab you forgot. lsof names it either way.

When lsof shows nothing

The hold may be a zombie: an app quit uncleanly and the kernel has not released the handle. Relaunching Finder (⌥-right-click its Dock icon → Relaunch) clears Finder's own holds; logging out clears almost everything; restarting clears everything. Escalate in that order — a restart for one file is usually unnecessary.

Emptying the Trash variant

The same error at empty-Trash time means something in the Trash is held open. Either lsof the specific file, or bypass with an immediate delete: select the file, then ⌥⌘⌫ deletes without the Trash stage entirely — appropriate once you know why the hold existed.

Common questions

What does lsof actually do?

It lists open files. Given a path, it prints every process with that file open — turning the vague in-use error into a specific app name.

Can I force-delete without finding the process?

Restarting releases all holds and the delete then succeeds. It works; it is also the slowest possible way to close one file handle.