Empty the Trash on a Mac when one file refuses to go

Emptying the Trash on a Mac is a one click job right up to the moment it is not. Everything disappears except a single folder, or the progress window counts down and then stops, or a dialog says the item is in use by something that appears to be closed. At that point the search term stops being about the menu item and starts being about the one file.

There are only a handful of causes, and each one has a specific fix rather than a general remedy. Worth saying first, because it changes how carefully to proceed: Apple's documentation is explicit that any items emptied from the Trash are permanently deleted and no longer available. Nothing below is reversible once it runs.

Four routes, and what each one skips

The Finder offers more than one way to do this, and they are not interchangeable. The differences show up exactly when something is stuck.

Route	How	What it does differently
Empty button	click the Trash in the Dock, then Empty in the upper-right corner of the Finder window	acts on everything listed, shows the warning
Menu	Finder > Empty Trash, or Shift-Command-Delete	same result, reachable without opening the window
Skip the warning	Option-Shift-Command-Delete, or hold Option while clicking Empty	empties with no confirmation dialog
One item only	Control-click the item in the Trash, then Delete Immediately	leaves everything else in place

The fourth row is the one that matters for a stuck Trash, and it is the step most people skip. If a single item is blocking the operation, deleting the rest one at a time with Delete Immediately isolates the problem to a named file instead of leaving a whole Trash in limbo. The shortcut reference Apple publishes lists Command-Delete to move an item to the Trash, Shift-Command-Delete to empty it, and Option-Shift-Command-Delete to empty it without the confirmation dialog.

Anything still in the Trash can also go back where it came from. Selecting it and choosing File > Put Back returns it to its original location, which is a better first move than dragging it to a new folder and losing track of where it belonged.

Four reasons one item stays behind

The stuck item is almost always one of these, and they can be told apart before touching anything.

The file is open. Something still has a handle on it, and macOS will not remove it while that is true. The process holding it is often not the obvious app: a preview, a background indexer, or a document window on another Space. Apps quit and reopened without a restart are a common source of this, because the original process may still be finishing work. lsof, which lists open files, takes a path and reports which processes are using it, which turns a vague error into a named application.

The file is locked. This is a flag on the file rather than a permission, and it has a precise name in the file system. It gets its own section below.

The permissions do not allow it. The Trash is per user, and an item that arrived from another account or from a system location can carry ownership that the current user cannot remove. Apple's own instructions for unlocking a file note that a Mac may ask for an administrator name and password, or Touch ID, or an Apple Watch, which is the same authorisation this case needs.

The item is not what it looks like. A Recovered Files folder and an item deleted from iCloud Drive both behave differently from a normal file, and both are covered further down.

Locked is a file flag, and it has a name

The Finder calls it Locked. Underneath, it is the user immutable flag, written uchg in the tools that manage it.

The route through the interface is short. Select the item, choose File > Get Info or press Command-I, then deselect the Locked checkbox. If the checkbox is dimmed, click the padlock and provide an administrator name and password, or authenticate with Touch ID or an Apple Watch. Apple notes that moving a locked item to the Trash produces a confirmation first, and clicking Continue accepts it, so a locked file can already be sitting in the Trash unable to leave.

The command line view is more informative when several files are involved. ls -lO includes the file flags in a long listing, which is the documented way to see which files carry which flags. chflags changes them, and its keyword list distinguishes two cases that look identical in the Finder. uchg, the user immutable flag, can be set or cleared by the owner or the super user, and nouchg clears it. schg, the system immutable flag, is super user only. A file carrying schg will resist an ordinary unlock attempt for a reason that has nothing to do with the Finder.

The distinction is worth knowing before escalating. A whole folder of locked files, which happens after restoring from certain backups or copying from a read only disk, clears in one pass rather than one dialog at a time. The chflags manual documents a recursive form for exactly that shape of problem, with -R applying to the file hierarchies rooted in the named files, and its own worked example clears every flag on a directory tree at once. The manual also carries a warning that belongs on any recursive command: wildcards like .* can unintentionally match the hard link to the parent directory, which turns an operation on one folder into an operation on its neighbours.

One more flag is worth recognising when it appears in that listing. hidden is described as hiding the item from the graphical interface, which explains files that exist, refuse to be deleted, and cannot be seen in the Finder at the same time. It is cleared the same way as the others, by prefixing the keyword with no.

Recovered Files folders are not the files that were deleted

A folder named Recovered Files appearing in the Trash after a restart looks like a deletion that failed. It is the opposite. Apple's page on recovered files in the Trash explains that these are temporary files used by macOS apps, that an app normally deletes its own temporary files when it no longer needs them, and that an app quitting unexpectedly may not get the chance. On restart, macOS moves those leftovers to the Trash.

Two consequences follow. First, the contents are usually safe to discard, and Apple's advice for anything uncertain is to check with the developer of the app in question. Second, and more practically, these folders appear after every unexpected quit, so a Trash that keeps refilling with them is reporting a crashing app rather than a Trash problem. Anything useful can be dragged out before emptying.

Some items are not governed by Finder settings

Two categories behave on their own schedule regardless of what the Trash is configured to do.

Items moved to the Trash from iCloud Drive are automatically emptied after 30 days, and Apple's wording is explicit that this happens regardless of Finder settings. Emptying sooner is possible. Waiting longer is not. For anyone using the Trash as an informal holding area, that is a hard deadline on anything that came from iCloud Drive, and it is invisible in the Finder window, which lists those items next to local ones with no visual difference.

Recovering something already past that point is no longer a Finder question. Apple directs deleted iCloud Drive items to the recovery tools on iCloud.com rather than to anything on the Mac.

The 30-day setting and the warning

Both live in the same place: Finder > Settings, then the Advanced pane.

"Remove items from the Trash after 30 days" turns the Trash into a rolling window instead of an archive. Apple's note on it is worth reading before switching it on, because items removed automatically are permanently deleted and no longer available, with no prompt at the moment it happens. The suggested precaution is a Time Machine backup or a copy on a storage device.

"Show warning before emptying the Trash" is the confirmation dialog. Turning it off makes every empty silent. The middle option is to leave it on and hold Option when a particular empty does not need confirming, which keeps the safety net for the ordinary case.

There is a reasonable pairing here for anyone whose Trash routinely holds tens of gigabytes: leave the warning on, turn the 30 day removal on, and stop treating the Trash as storage. The failure mode of the opposite arrangement is discovering that a file needed in March was removed in February.

The terminal route does not do what people think

rm deletes without the Trash, and it is the standard answer in forum threads about a stuck Trash. It is worth understanding what it does and does not provide.

It removes rather than moves, so there is no undo and no Put Back. -f attempts removal without prompting regardless of the file's permissions, which is why it appears in every copied one liner and also why it is the flag that turns a typo into a loss. -i prompts for every file; -I prompts once if more than three files are involved or a directory is being removed recursively, which the manual describes as far less intrusive while giving almost the same protection. -v prints each name as it goes. -x stops a recursive removal from crossing mount points, which matters when external volumes are attached.

Two behaviours are easy to get wrong. rm removes symbolic links themselves, not the files they point to. And it is an error to attempt to remove /, . or .., which is a guard rail rather than a feature to rely on.

The one that punctures a widespread belief is -P. It was the option that overwrote file contents before unlinking them, and the current manual states plainly that the flag has no effect and is kept only for backwards compatibility with 4.4BSD-Lite2. Deleting a file on a modern Mac does not overwrite its contents, whether from the Finder or the terminal. Anyone who needs data genuinely unrecoverable is looking at full disk encryption and key destruction, not at a delete command.

Note also that rm does not bypass a locked file. The immutable flag stops it too, which returns the problem to chflags.

What to change first

Before anything else, isolate the item: Control-click it in the Trash and use Delete Immediately so the failure is about one named file rather than the whole Trash. Then check ls -lO for a uchg or schg flag, and only after that reach for the terminal. Since this work moves between a Finder window and a shell for every single file, keeping the two in one window removes most of the back and forth; Atriens is built that way, and the FAQ covers what it does and does not replace.