9

When I try to delete a file

sudo rm -rf filename

I get spit back:

rm: filename: Resource is busy

How can I override this? I know for a fact that the resource is not busy. I just want to delete it!

9
  • 3
    The operating system says it is. Should we trust the computer or the human? Do you have the file selected in any GUI? Is it actually a directory (noting that you used the -r flag)? Is it perhaps open in a background or zombied process?
    – paddy
    Feb 12, 2013 at 22:26
  • 2
    And so you are therefore certain that the file is not being used by a process that is started when your system starts? The key to being a good problem solver is to not trust anything you're told. I don't trust you, and I don't trust your operating system. With a level playing field, we can make some progress into understanding what is going on. If we accept all your assumptions as true, we will make no further progress than you have already, and look where you are right now.
    – paddy
    Feb 12, 2013 at 22:33
  • 1
    It's BUSY! The OS is not going to have a bar of it. Furthermore, you are ignoring what is being said and returning to "answer the question". Have you tried booting your system from an image on a flash drive or whatever, mounting the partition in question and deleting the file?
    – paddy
    Feb 12, 2013 at 22:42
  • 2
    Then I misunderstood the last part of your question where you say "I just want to delete it!" You don't seem open to advice on how to achieve this, so I recommend you continue to follow your own path without asking for help.
    – paddy
    Feb 12, 2013 at 23:01
  • 5
    It would have been more entertaining to future readers if CodeGuy had not deleted all his rude and insulting comments. The above reads as if I'm having an argument with myself... =)
    – paddy
    Mar 25, 2015 at 4:34

11 Answers 11

10

Try lsof filename to see if it's really busy. One of the most common causes of this is that you're trying to remove a directory that you have a shell open in.

1
  • 5
    Did you try the command? Unix usually doesn't lie about things just to mess with you. Feb 12, 2013 at 22:31
10

You cannot override this behaviour.

The operating system states that it is busy. The operating system is probably correct. The error message could be for these reasons:

  • the file is actually being used by another process
  • there is a problem with your file system

As you wish to delete the file, my suggestion has been to boot the machine from a linux image, mount your file system and delete the file.

1
  • One could add, that Apple's "Preview" is a common reason for random files to be "busy" if you previewed them with the space-bar "QuickLook" feature. I absolutely hate it and it is driving me nuts. I would also suggest adding the lsof file and how to proceed - kill the PID and then delete the file. One could also write a hard-core-delete script, that does this. But yes, that is far beyond answering a simple question like this ;)
    – rwenz3l
    May 12, 2014 at 16:10
1

As other posters say, if you know better then the OS, reboot the system and that will make it forget. But really, they know what they are talking about...

1

This is an old question but I'll add my 2 cents, because there are in fact situations where a file is not really in use but the OS still thinks it is.

It is possible for a file on a removable device to be in use during a system crash and the system will continue think the file is still in use, even if lsof returns nothing and the file is not really in use. Deleting .DS_store has no effect.

Temporarily, one can rename the file or folder if needed. Then whip out the disk utility and do repair disk/repair permissions on the volume.

1

All of the above. The system does not usually lie, meaning that sometimes it does.

Read on, because I had a unique situation in which none of the previously suggested solutions worked, but I did manage to solve my problem.

In my case the "busy" file was a .ttf TrueType font file on a "foreign disk" on a network attached drive, and therefore not likely to be opened by the system on startup. The lsof command showed nothing. A reboot of the mac did not change anything. Shutting down the only other computer on the network that might conceivably be using the file did not change anything.

Disk Utility couldn't do anything with the drive, because it wasn't just a removable device, it was a remote device, not attached directly to the Mac.

I copied the file with a new name, because in my case I wanted to rename it, not delete it. After copying I couldn't delete the original because it was still "busy."

I logged into the network attached drive and attempted to "check" the "foreign disk" but the check failed. But now I was able to delete the original file--in Finder, without using sudo or rm -f or anything like that. It was no longer "busy."

1

The easiest thing you can do is

lsof +D /path/in/question

You'll get a list of processes that have a hold on that process

Kill the processes that are listed

kill -9 <numberOfProcessID>

Obviously without the <'s

1

My 2 cents. I had the same problem -- I was using the terminal to copy some files to a temporary location in a Drobo share. It was taking too long so I decided to process them in other way, and ^C the cp command and erased the temporary files.

One of the files remained. When I try to erase it, either via command line or Finder, I get the The operation can’t be completed because the item “123.mp4” is in use. message from Finder or Resource busy from the terminal.

The funny part is that I am able to clobber the file. I can copy other file to it, and cat > 123.mp4 with any nonsense works. The file size even reflects the changes I did.

lsof 123.mp4 returns nothing.

The only way I was able to get rid of this evil zombie file was unmounting the share and remounting it.

0

I had a similar problem when the main.css file got locked when changing from one branch to another in Git. The repo was on a file server and I was connected with SMB. My client is a Mac running OSX 10.10.5 (Yosemite).

Rebooting the client didn't help. I couldn't switch branches. I couldn't git stash. I couldn't just rm the file. I was stuck.

Then I realized that I could access the server directly. There, I was able to rm the file and then checkout a new version. Back on my client, everything was instantly fine.

Just in case it's of use to someone else who finds this thread the way I did.

0

Fire up disk utility and check whether there is an image mounted which corresponds to that directory name. Eject the image and the directory will be gone.

0

I did what the message asked by checking that the file wasn't locked, that I had proper permissions in the little CMD+I window, then again in the terminal to check owner and group permissions...lsof +D on one of the directories in question yielded "Finder." Unsure of whether that was bc I had a Finder window open, or if it was something else, I relaunched Finder. I unmounted and remounted the remote drives and disabled Spotlight indexing of the drives. Nothing worked.

In the end, I had to go into QNAP's GUI file manager and delete them from there. I don't know if it had some process running on it, but whatever the situation, I had to use QNAP's software to fix it.

0

On a Synology NAS DiskStation I had a file that I could not delete from the MacOS Finder or Terminal due to the "resource is busy" issue. However, I could delete it by connecting to the Synology interface via a web browser (http://169.254.216.146:5000/) and deleting the file in the File Station application.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .