"The operation can't be completed because the item is in use" is one of the more frustrating errors in macOS, mostly because it rarely tells you which item, or what's using it. Emptying the Trash normally is a one-click, invisible operation, so when it fails, most people either give up or reach for a forceful command they don't fully understand. There are really only a handful of actual causes, and each has a specific, low-risk fix — no reason to guess.
Cause one: the file is genuinely open somewhere
The most common reason is also the simplest: an application still has the file open, even if you don't remember opening it. A document mid-save in an app you quit unexpectedly, a video file a media player still has a handle on, or a file an app is watching in the background (sync clients are frequent culprits) will all block deletion.
Check Activity Monitor, but more usefully, just quit anything you don't need running and try again. If you don't know which app it is, restarting the Mac clears every open file handle unconditionally, which is a legitimate fix here, not just a "turn it off and on again" deflection — it genuinely resolves this specific cause because nothing survives a restart with a file still held open.
Cause two: permission mismatches
If a file was created by a different user account, moved from an external drive with different permissions, or extracted from an archive that preserved unusual ownership, your account may not have permission to delete it even though it's sitting in your own Trash. Check ownership and permissions:
ls -la ~/.Trash/problem-file
If the owner shown isn't your username, you'll need to take ownership before macOS will let you delete it:
sudo chown $(whoami) ~/.Trash/problem-file
Only run sudo commands you understand the effect of, and only on the specific file causing the problem — not as a blanket fix applied to the whole Trash folder without knowing why.
Cause three: the locked or "no user changes" flag
Finder's own Get Info → Locked checkbox, or the underlying uchg (user immutable) file flag it sets, prevents a file from being deleted or modified until unlocked. Files marked locked this way will silently refuse to empty from Trash without any clear error explaining why.
Check for the flag:
ls -lO ~/.Trash/problem-file
If you see uchg in the flags column, clear it:
chflags nouchg ~/.Trash/problem-file
This is the exact scenario the chflags nouchg command exists for — reversing a lock that's blocking deletion, on a file you've already decided you want gone (it's in the Trash, after all).
Cause four: it's not actually in your Trash, it's on another volume
Every mounted volume — external drives, additional internal APFS volumes, network shares — has its own hidden Trash folder at /Volumes/<volume name>/.Trashes/, separate from ~/.Trash on your boot drive. Files you delete from an external drive go there, not to the Finder Trash icon's usual location, and if that external drive is disconnected before you empty Trash, macOS can get confused about whether the deletion actually completed.
If Trash won't empty and you've recently deleted something from an external drive, reconnect that drive before trying again — emptying Trash needs to reach the volume the file actually lives on, not just your boot drive.
Cause five: Time Machine local snapshots referencing a deleted file
Occasionally a file appears successfully removed from Trash, but the space isn't reclaimed, because an APFS local snapshot still holds a reference to it. This isn't a "Trash won't empty" problem exactly — the file is gone — but it produces the same symptom of "I deleted this and my space didn't change." Check for lingering snapshots:
tmutil listlocalsnapshots /
If there are several, especially old ones, this explains space that looks stuck even after a successful Trash empty.
A sensible troubleshooting order
| Symptom | Likely cause | Fix |
|---|---|---|
| "Item is in use" error | Open file handle | Quit the app, or restart if unsure which one |
| No error, but nothing happens | Permission mismatch | Check and correct ownership with chown |
| Locked checkbox was ever set | uchg flag |
Clear with chflags nouchg |
| Deleted from external drive | Separate .Trashes folder |
Reconnect the drive, then empty |
| Space not reclaimed after emptying | Local snapshot reference | Check tmutil listlocalsnapshots |
Work through these in order rather than jumping straight to force-deleting from Terminal — the underlying cause is almost always one of the five above, and each has a fix that doesn't require bypassing macOS's safety checks blindly.
When to actually use a forceful delete
If you've ruled out all five causes and a file genuinely won't go, sudo rm bypasses Finder's Trash mechanism entirely and deletes immediately and permanently, with no further confirmation and no way to recover the file afterward. Treat this as a last resort for a single, specifically identified file — never as a routine way to empty a stubborn Trash, and never recursively across a folder you haven't reviewed file by file.
Restarting versus safe mode
A regular restart clears open file handles, as mentioned above, but if a Trash issue persists across a restart, booting into Safe Mode (hold the power button on Apple Silicon, then choose Safe Mode from the startup options) goes a step further by disabling third-party login items and kernel extensions that could otherwise be holding a file open in the background — a sync client or a security tool, for instance. If Trash empties successfully in Safe Mode but not in a normal restart, that's a useful clue that a specific background app, not the file itself, was the actual cause.
Checking Console for the real reason
macOS's own Console app logs the specific error when an operation like emptying Trash fails, which is often more informative than Finder's generic "item is in use" dialog. Open Console, search for "Finder" around the time the failure occurred, and look for a line mentioning the specific file or the specific reason the operation was denied — this can save several rounds of guessing between the causes above.
Where VolumeLens comes in
None of the above is something a storage tool should do for you silently — permission and lock issues need a deliberate decision, not an automated override. What VolumeLens does instead is show you, before anything reaches the Trash, exactly what's included and its real size, so you're not troubleshooting a stuck Trash full of items you don't remember deleting or don't actually want gone.