Sweepfor Mac

Troubleshooting

'Resource Busy' Error on Mac When Deleting a File? Here's the Fix

Mac says 'resource busy' when deleting a file? Here's how to find the process holding it, force the delete, and prevent the error coming back.

7 min read

You drag a file to the Trash and Finder shrugs: “The operation can’t be completed because the file is in use.” Or in Terminal: rm: <file>: Resource busy. Or you try to eject a drive and get “The disk wasn’t ejected because one or more programs may be using it.” Same family of errors — some process on your Mac has a handle on that resource and the OS won’t let you yank it out.

This is one of the most fixable error classes on macOS once you know how to identify the offending process.

What “Resource busy” actually means

In Unix terms, EBUSY (error number 16) means an operation can’t proceed because the resource is in use. On macOS:

  • A process has the file open with an exclusive lock.
  • A process is reading from or writing to the file.
  • The file is being mmap’d (memory-mapped) by a running process.
  • The file is part of a volume that’s currently being indexed by Spotlight.
  • It’s a system file with locked attributes.

The error wording varies:

  • “The operation can’t be completed because the file is in use.”
  • “Resource busy” (Terminal).
  • “The disk wasn’t ejected because one or more programs may be using it.”
  • “Couldn’t unmount disk.”

Quick fixes for everyday cases

1. Quit the app you suspect

If you know which app likely opened the file (you were just editing it in Photoshop, you streamed it in QuickTime), quit that app and retry.

2. Check for running helpers

Big apps spawn helper processes that linger. Open Activity Monitor, search for the app’s name, force-quit anything related. Adobe, Microsoft, and Dropbox all have helpers that hold files open after the main app is closed.

3. Restart the Mac

Terminates every process. Whatever was holding the file releases on shutdown. The brute-force solution that always works for transient busy states.

Skip the manual huntSweep clears the cruft that triggers most of these errors — caches, logs, leftover daemons. Download Sweep free →

Find the culprit with lsof

lsof (list open files) tells you exactly which process has the file open.

lsof /path/to/the/file

Output looks like:

COMMAND     PID   USER   FD   TYPE DEVICE  SIZE/OFF NODE NAME
Photoshop  4521    you   txt   REG  1,5  100483072  ... /Users/you/Documents/big.psd

The PID column is the process ID. Quit that process via Activity Monitor, or in Terminal:

kill <PID>

If kill doesn’t work, escalate:

kill -9 <PID>

The -9 is SIGKILL — uncatchable, the process dies immediately. Use sparingly because the process can’t clean up afterward, but for stuck-busy resources it’s the right tool.

For a whole directory:

lsof +D /path/to/folder

Shows every open file beneath that folder. Useful when you can’t eject a drive.

When you can’t eject a drive

The eject failure is the most common form of this error. To find what’s holding it:

lsof | grep "/Volumes/DriveName"

Look at the COMMAND column. Common culprits:

  • mds and mds_stores — Spotlight indexing the drive.
  • fseventsd — file system events daemon.
  • bird — the iCloud Drive daemon if iCloud is configured to use the volume.
  • VirtualBox or Parallels — if a VM image is on the drive.
  • Backup and Sync from Google or Dropbox — sync clients.
  • Any text editor or Photoshop — the file you opened.

Quit the offending process and try eject again.

For Spotlight specifically, you can disable indexing on the volume to release the locks:

sudo mdutil -i off /Volumes/DriveName

Re-enable later with mdutil -i on.

Tip: If lsof shows nothing but eject still fails, try right-clicking the volume in Finder and choosing "Eject" — the desktop icon sometimes lags behind the actual mount state.

Force the eject

If a polite eject won’t work and the drive is genuinely safe to remove (you’ve verified no critical writes are pending):

In Disk Utility, select the drive in the sidebar → Unmount. Sometimes Disk Utility succeeds where Finder doesn’t.

Terminal:

diskutil unmount force /Volumes/DriveName

The force argument terminates active connections. Use only when standard unmount fails and you’ve checked nothing critical is mid-write.

Specific scenarios

Trash that won’t empty: “in use” on every item

Restart the Mac. Then immediately empty Trash before opening any other apps. If a specific file persists, identify it with lsof ~/.Trash/<filename> and kill the holder.

”in use” on a file just now downloaded

The browser still has the download open. Quit the browser fully, then delete.

”in use” on a folder you’re inside in Terminal

cd out of the folder before deleting. Your shell’s working directory keeps it open.

”in use” on a video you’re streaming

QuickTime, VLC, or your browser is reading the file. Stop playback and close the player.

”in use” because of Time Machine

Time Machine briefly locks files during snapshots. If errors cluster on hourly intervals, that’s why. Pause Time Machine via the menu bar icon, perform your operation, resume.

”in use” by Spotlight

mds and mds_stores index everything. During heavy indexing — first hour after macOS upgrade, after migrating large libraries — they hold many files open. Wait it out, or temporarily disable Spotlight on the volume.

Diagnose AND clean in one appSweep finds the buildup behind the error and clears it. Try Sweep free →

When sandbox containers misbehave

App-sandboxed apps store data in ~/Library/Containers/<bundle-id>/. If the app crashed mid-write, files in those containers can stay marked as in-use indefinitely.

launchctl list | grep <bundle-id>

Find the corresponding launchd entry. Boot it:

launchctl bootout gui/$(id -u)/<launchd-label>

Then retry deletion.

Network drive “resource busy”

SMB and AFP shares often fail to release files cleanly when the connection drops. Disconnect the share entirely:

  1. Finder → click the eject button next to the share.
  2. If it refuses, in Terminal: umount -f /Volumes/ShareName.
  3. Reconnect, then perform your operation cleanly.

For NAS volumes, sometimes the NAS itself has a lock on the file from a different user or a stalled SMB session — restarting the NAS clears those.

Disk Utility First Aid leaves resource busy

If First Aid says it can’t repair the volume because it’s “in use”:

  1. Boot into Recovery Mode (Apple Silicon: hold power, choose Options; Intel: Cmd+R).
  2. Disk Utility → run First Aid from there.

Recovery Mode boots a minimal environment with no user processes holding files open, so First Aid can do its job.

Specific to external SSDs

Some SSDs (Samsung T7 specifically) had firmware issues that caused them to register as in-use even after no process had them open. Updating the drive’s firmware via Samsung Magician (run on a Windows PC if needed; the Mac version is limited) resolves it for that family.

Resource busy in scripts and automated workflows

If you’re running a backup script or rsync job and resources are busy:

  1. Check that no other instance of the script is running: ps aux | grep rsync.
  2. Make sure file watchers (Dropbox, iCloud, Google Drive) are paused during heavy file ops.
  3. For repeated runs, add retry logic — many transient busy states resolve in seconds.

When to suspect Spotlight or fseventsd

If you see mds, mds_stores, or fseventsd in lsof output for files you can’t delete, those are macOS background services indexing the filesystem. They’re not stuck; they’re doing their job.

To temporarily release everything:

sudo mdutil -i off /
sudo mdutil -i on /

The off/on cycle restarts indexing fresh. Don’t leave Spotlight off — system search depends on it.

When the file is genuinely corrupt

Sometimes the file’s metadata is so damaged that no process can complete operations on it, and lsof shows nothing. In Terminal:

sudo rm -f /path/to/file

If that fails: First Aid the volume. If First Aid can’t fix it, the volume may be failing — back up and replace.

When the answer is hardware

Persistent “resource busy” errors that ignore lsof results usually point at a failing drive. Check S.M.A.R.T. status (Disk Utility → View → Show All Devices → click the physical drive), watch for clicking sounds from spinning drives, and search Console.app for I/O errors.

A drive with unrecoverable read errors on specific blocks will hang any process that touches those blocks, leaving them appearing in-use forever.

Prevent it from coming back

  • Always quit apps fully before deleting their files.
  • Use the eject button on external drives.
  • Don’t keep VMs or Time Machine destinations on drives you eject often.
  • Restart the Mac at least weekly to clear long-running processes.

lsof is the closest thing to a Swiss Army knife for resource-busy errors. Five seconds with it tells you exactly what’s holding the file, and the fix follows naturally.

← Back to all guides