Force delete a file the Mac Trash will not let go of

The Trash emptied, a progress bar appeared, and one item is still sitting there. Or the whole operation stopped on a single file with a message about the file being in use, or being locked, or the operation not being permitted. The advice that comes back from a search is almost always the same command, prefixed with sudo, applied without asking what the refusal meant. That is why it sometimes works and sometimes changes nothing.

Removing a file on a Mac is not one operation with one failure mode. It is a request to remove a directory entry, and the file system can refuse that request for reasons that have nothing to do with each other. A file held open by a running process, a file carrying an immutable flag, and a file sitting in a folder you cannot write to all produce a stuck item in the Trash, and each one needs a different move. Working out which of the three is in play takes about a minute and saves the guesswork.

What emptying the Trash actually does

Moving something to the Trash is a rename, not a deletion. Apple's own description of the behavior is worth having in hand, because the sequence it describes is where the confusion starts:

At any time, you can get rid of files, folders, and other items that you no longer need. You start by dragging items to the Trash in the Dock, but the items aren't deleted until you empty the Trash. Source: support.apple.com

So a file in the Trash still exists in full, at a new path, with the same owner, the same permissions and the same flags it had before. Nothing about it changed when it went in. Emptying is the step that asks the file system to unlink it, and that step can fail on any of the conditions that were already true of the file.

This matters for a practical reason. Every property that will block the deletion can be inspected while the item is still in the Trash, using the same Get Info window and the same commands that would work anywhere else. There is no need to drag the file back out first, and dragging it out changes nothing about whether it can be removed.

There is one exception worth knowing. Apple notes that items moved to the Trash from iCloud Drive are emptied automatically after 30 days regardless of Finder settings. An item that keeps reappearing, or that vanishes on its own before anything is done to it, may be on that clock rather than stuck.

The Option key is not a force switch

The most repeated piece of advice for this problem is to hold Option while choosing Empty Trash. It is real, it is documented, and it does something other than what people expect. Apple lists it under preventing the Trash warning message from appearing, alongside the permanent equivalent in Finder settings under Advanced, where "Show warning before emptying the Trash" can be turned off.

That is the whole effect. Holding Option skips the confirmation dialog for that one action. It does not raise privileges, it does not clear flags, and it does not close files that other processes have open. Anyone who has been holding Option and watching the same item survive now knows why.

The genuinely useful Finder move is the one that works on a single item. Control-click the item inside the Trash window and choose Delete Immediately, then click Delete in the warning. That removes one item rather than the whole Trash, which is how a folder of several hundred files gets narrowed down to the one file that is actually blocking the operation. Until that narrowing happens, every error message is ambiguous about which item produced it.

When something has the file open

This is the most common cause by a wide margin, and it is the one that produces a message about the file being in use. The file is fine, the permissions are fine, and a running process is holding it.

lsof answers the question directly. Passing it a path lists the processes with that file open. For a directory, +D is the option that matters: the manual page describes it as searching for all open instances of a directory and all the files and directories it contains to its complete depth. Pointed at the Trash folder, that returns the list of everything currently holding anything inside it, with the process name in the first column.

Two caveats from the same manual page save some confusion. +D does not follow symbolic links inside the directory unless -x is also given, and it does not cross mount points onto subdirectories unless -x f is given. It also notes that the authority of the user running it limits the search to files that user has permission to examine, so a partial list is a normal result rather than a sign that nothing is open.

The fix is to quit whatever is named. The usual culprits are not the app the file came from. Backup agents, antivirus scanners, cloud sync clients and media indexers open files in bulk and keep them open for a while, and any of them can hold something in the Trash. If the process is a background agent with no window, logging out and back in releases every file descriptor the session owned, which is a smaller intervention than restarting and usually enough.

When the file is locked

A locked file is a distinct condition with its own visible marker. Apple's page describes both sides of it: moving a locked item to the Trash requires clicking Continue to confirm, and the lock is cleared by selecting the item, choosing File then Get Info, or pressing the Command-I shortcut, and deselecting the Locked checkbox. If the account in use is not an administrator, the padlock in that window has to be unlocked with an administrator name and password first.

Underneath the checkbox is a file flag, and the command line view of it is more precise. chflags documents the relevant keywords, and the difference between two of them explains why some locked files yield to an administrator and others do not.

Flag	Manual page description	Who can change it
uchg	user immutable flag	owner or super-user
schg	system immutable flag	super-user only
sappnd	system append-only flag	super-user only

ls -lO prints the flags on existing files, which the chflags manual page names as the way to check. Clearing the user immutable flag on a tree is chflags -R nouchg followed by the path, since prefixing a keyword with no clears it. The manual page also gives chflags -R 0 as the way to clear every flag on a hierarchy, which is worth reaching for only when the goal really is all of them.

One detail catches people editing flags by hand. On a symbolic link, chflags always succeeds and has no effect unless -h is given, which means a command that appeared to work may have done nothing at all.

When the permission that matters is on the folder

The third refusal is a permissions problem, and it is usually misdiagnosed because the wrong item gets inspected. Removing a file means removing its entry from the directory that contains it, so the permission that has to allow it is write permission on that directory. A file whose own permissions read as fully writable will still refuse to be deleted if its enclosing folder does not allow writing.

Apple's instructions for changing permissions for files, folders or disks describe the Get Info route: select the disk, folder or file, choose File then Get Info, expand Sharing & Permissions, click the padlock to unlock the settings, then choose a privilege setting for the relevant user or group. Read & Write is the setting that allows an item to be opened and changed. For a folder full of items that all refuse, the same panel offers "Apply to enclosed items" from the action menu at the bottom, and ownership can be reassigned there with the "Make [user name] the owner" option.

The same page notes that changes made in Sharing & Permissions since the Info window was opened can be undone with "Revert changes" before the window is closed. That is the safety net for a folder where the permissions were adjusted more broadly than intended.

What rm does and does not do

The command every search result recommends is rm -rf, and reading its manual page changes how it should be used here. rm attempts to remove the files named on the command line, and prompts for confirmation if the permissions do not permit writing and standard input is a terminal. -f attempts removal without prompting regardless of the file's permissions, and, in the words of the manual page, if the file does not exist it will not display a diagnostic message or modify the exit status to reflect an error. -R removes a file hierarchy and implies -d, and -r is equivalent to -R.

Read that description of -f again, because it is the reason this command gets used badly. -f suppresses the diagnosis. Running it on a file held open by a process, or carrying a system immutable flag, produces less information than running it without the flag, and a silent failure looks identical to a silent success. When the question is still why the file will not go, the first attempt should be without -f, so the error text names the cause.

-I is the option worth adopting as a habit: it requests confirmation once if more than three files are being removed or if a directory is being removed recursively, which the manual page describes as far less intrusive than -i while providing almost the same protection. There is also a hard limit built in, since the manual page states that it is an error to attempt to remove /, . or .., and one behavior that surprises people: rm removes symbolic links, not the files they reference.

The permanent difference from the Trash is the one to sit with. rm unlinks immediately and there is no Put Back.

The command that moves things to the Trash instead

For anything scripted, there is now a middle option that did not used to exist. macOS ships a trash command, and its manual page states that it first appeared in macOS 15.0. It moves files and directories into the user trash folder, taking -v for verbose output and -s to exit with an error if any move fails.

The reason to prefer it in a cleanup script is that its result is reversible. A script that calls rm on a computed list of paths has no recovery path when the list is wrong. A script that calls trash leaves everything it touched sitting in one place, visible, with Put Back available. The -s flag matters for the same reason, since a loop that keeps going after a failed move produces a partial result that nobody notices.

Refusals that no flag will get past

A few causes are not about the file at all, and recognizing them stops a long detour.

Symptom	What to check	What changes it
Operation not permitted on a system path, even as root	System Integrity Protection	Nothing routine. SIP protects system locations from the root user
Errors across many files on one volume	Disk Utility First Aid on that volume	Repairing the volume, before deleting anything else
Nothing on a volume can be changed	Whether the volume is mounted read only	Remounting or reformatting, depending on the cause
Item reappears after deletion	A sync client restoring it	Pausing the sync client, then deleting

System Integrity Protection is the one that produces the most wasted effort, because the error text looks like an ordinary permissions problem and sudo does not resolve it. Apple's developer documentation covers how SIP is disabled and enabled, and the short version for this problem is that files protected by it are not meant to be removed by hand.

A volume that needs repair deserves attention before anything else, because deletion failures spread across unrelated files are a symptom rather than the problem. Apple's Disk Utility guide covers repairing a storage device with First Aid, and running it costs nothing.

What to change first

Use Delete Immediately on one item to find out which file is actually stuck, then run lsof on it before reaching for any flag, because a file held open by a process is the most likely answer and the only one that sudo cannot fix. Checking a file's flags in a folder view and running the matching command in the same window is the friction a file manager with a built-in terminal removes, which is what Atriens is built around, and the questions that come up most often are collected in the FAQ.