"The operation can't be completed because the item is in use"

23 August 2026 · 7 min read

You drag a file to the Trash and macOS stops you: the operation can’t be completed because the item “clip.mov” is in use. Nothing visible is open. You quit the obvious app, try again, and get the same dialog. This is one of the more misleading messages the Finder produces, because “in use” covers at least four unrelated situations, and only one of them means what you would assume.

The fix depends entirely on which one you have. Below is how to tell them apart in about a minute, starting with the command that answers the question directly.

First, find out what is actually holding it

macOS knows exactly which process has the file open. The Finder simply does not tell you. Open Terminal and run lsof with the path to the file. The easiest way to get the path right is to type lsof (with the trailing space) and then drag the file from the Finder into the Terminal window, which pastes the full path for you.

lsof /Users/you/Movies/clip.mov

If something has it open, you get a table like this:

COMMAND   PID     USER   FD   TYPE DEVICE     SIZE/OFF      NODE NAME
QuickTime 4821 you       12r  REG    1,14     23514721  352874138 /Users/you/Movies/clip.mov

The COMMAND column is the app. The PID is its process number. That is your answer: quit that app, and the file is released. If the app is not responding, quit it from Activity Monitor, or from Terminal with kill 4821 using the PID from your own output.

If lsof prints nothing at all, no process has the file open, and you are in one of the other three situations below. That is a genuinely useful result, because it rules out the obvious explanation immediately and saves you restarting the Mac for no reason.

Situation two: the file is locked, not in use

macOS has a per-file Locked flag that predates the modern permissions system, and the error it produces reads almost identically. Select the file, press Command-I to Get Info, and look for a Locked checkbox near the top. If it is ticked, untick it.

You can check and clear it from Terminal too, which is faster when several files are affected:

ls -lO clip.mov            # the letter O, not zero; look for "uchg"
chflags nouchg clip.mov    # clears the lock

The uchg flag in that output is the lock. Files arrive locked more often than people expect: some backup software sets it, some download managers set it, and files restored from a Time Machine backup can carry it. If a whole folder is affected, chflags -R nouchg foldername clears it recursively.

Situation three: the volume is the problem, not the file

If the file lives on an external drive, a network share, or a disk image, “in use” sometimes means the volume itself is busy rather than the file. This is common with drives formatted for Windows, where the Mac’s write support behaves differently from a native volume.

Two checks. First, is the drive formatted NTFS? Get Info on the drive and read the Format line. macOS mounts NTFS read-only by default, and a read-only volume produces permission and in-use errors that have nothing to do with any process. Second, is it a network share? An SMB mount can hold a lock on behalf of a machine that has already disconnected, and no amount of quitting apps locally will clear it. Eject and remount the share.

Situation four: nothing is holding it, and the Finder is confused

This is the frustrating one, and it is real. The Finder maintains its own state about open files, and that state occasionally survives the thing that created it. The symptom is specific: lsof returns nothing, the file is not locked, the volume is healthy, and the Finder still refuses.

Restart the Finder before you restart the Mac. Hold Option and right-click the Finder icon in the Dock, then choose Relaunch. Alternatively, from Terminal:

killall Finder

The Finder restarts immediately, and your windows come back. In most cases the file can now be moved. If it still cannot, log out and back in, which clears per-session state without a full reboot.

The one that catches everyone: Trash, not Finder

A particular version of this error appears when you empty the Trash rather than when you delete. The message names a file you do not recognise, and quitting apps changes nothing. What is usually happening is that something in the Trash is still open, often a file you deleted earlier in the session while an app had it loaded, or a disk image that is still mounted.

Check for mounted volumes first. Open Disk Utility and look for anything mounted from a .dmg you have already thrown away. Eject it, then empty the Trash. If the Trash still refuses, lsof works on the Trash directory too:

lsof ~/.Trash

When the file is a video, audio file or document

There is a second reason a media file resists deletion, and it is worth ruling out because the fix is different: the file may be damaged rather than busy. A truncated video, for instance, can make Quick Look hang while trying to generate a preview, and a hung Quick Look process holds the file open. You see “in use” and blame an app you never opened.

The tell is that lsof names QuickLookUIService or qlmanage rather than an app you launched. If so, the sequence is: kill the Quick Look process, then deal with the underlying damage.

qlmanage -r                 # reset Quick Look
killall QuickLookUIService  # stop the hung previewer

You can then check whether the file is actually intact. For video and audio, ffprobe reads the structure without decoding the whole file:

ffprobe -v error -show_entries stream=codec_type,codec_name,duration \
  -of default=noprint_wrappers=1 clip.mov

A healthy file prints one block per stream with a duration. A damaged file prints an error, or prints a video stream with no duration, which usually means the index at the end of the file never got written.

Manatee is built for the second half of that problem. Once the file is released, it can read what is left of a damaged video, audio file, PDF or Office document and write a clean copy, working from a duplicate so the original is never altered. What it will not do is unlock a file or quit an app for you; that part is the Terminal work above, and it is genuinely quicker by hand. If the diagnosis turns out to be damage rather than a lock, checking whether a video file is corrupted covers the tests in more depth.

A diagnosis order worth remembering

Run these in sequence and you will resolve this in about a minute rather than by rebooting hopefully:

lsof <file>. If a process appears, quit it. Done.
Get Info, or ls -lO. If Locked or uchg, clear it. Done.
Check the volume. NTFS or a stale network mount explains it. Eject and remount.
killall Finder. Clears stale Finder state.
Log out and back in. Clears session state.
Restart. Almost never necessary if the first five were done properly.

The reason for the order is that each step is cheaper than the one after it, and each rules out a distinct cause. Most guides to this error start at step six, which does often work, and teaches you nothing about why.

Questions

Why does the Finder not just tell me which app is using the file? It knows, and it has never surfaced it. The information is available to any process that asks the kernel, which is what lsof does. There is no user-facing equivalent in the Finder or Activity Monitor.

Is kill safe? Killing an app is the same as force-quitting it, so unsaved work in that app is lost. Quit it normally first and use kill only if it will not respond. Never kill a process you cannot identify, and be especially careful with anything owned by root.

The file is on a Time Machine backup and nothing works. Files inside Time Machine backups are deliberately protected, and the in-use error is one of the ways that protection surfaces. Do not fight it with chflags. Use Time Machine’s own restore interface, or the tmutil command, to get a copy out.

I get this for a file I already deleted. The Finder is referring to the copy in the Trash. Run lsof ~/.Trash to find the holder, and check Disk Utility for a mounted disk image whose source file is in the Trash.