Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
I tried to rm -rf a folder, and got "device or resource busy".
In Windows, I would have used LockHunter to resolve this. What's the linux equivalent? (Please give as answer a simple "unlock this" method, and not complete articles like this one. Although they're useful, I'm currently interested in just ASimpleMethodThatWorks™)
The tool you want is lsof, which stands for list open files.
It has a lot of options, so check the man page, but if you want to see all open files under a directory:
lsof +D /path
That will recurse through the filesystem under /path, so beware doing it on large directory trees.
Once you know which processes have files open, you can exit those apps, or kill them with the kill(1) command.
/path. That is one cause of hidden "open files".
lsof seems to do nothing for me: lsof storage/logs/laravel.log returned nothing, and so did lsof +D storage/logs/. umount responded with not mounted.
mount | grep <path>. That shows any /dev/<abc> might be mounted on the the <path>. Use sudo umount -lf /dev/<abc> and then try to remove <path>. Works for me. Thanks @camh
sometimes it's the result of mounting issues, so I'd unmount the filesystem or directory you're trying to remove:
umount /path
I had this same issue, built a one-liner starting with @camh recommendation:
lsof +D ./ | awk '{print $2}' | tail -n +2 | xargs -r kill -9
awk grabs the PIDs.tail gets rid of
the pesky first entry: "PID".xargs executes kill -9 on the PIDs. The -r / --no-run-if-empty, prevents kill command failure, in case lsof did not return any PID.
kill <no PID> failure (if lsof returns nothing) - Use xargs with -r / --no-run-if-empty. For non-GNU xargs, see this alternative: stackoverflow.com/a/19038748
Jun 10, 2020 at 7:29
tail -n +2 output through sort -u before killing the jobs IDs
Sep 16, 2021 at 10:58
kill -9 is a favorite for use but does have serious implications. This signal is "non-catchagable, non-ignorable" to the process. Thus, the process may terminate without saving critical state data. Perhaps a simple kill first, and if that doesn't work, then the -9? Finally, bear in mind that if the process is blocked on I/O, kill -9 isn't going to work. That's not an oversight in this suggestion, just something to keep in mind.
Jun 22, 2022 at 21:26
Here is the solution:
ls -a.xyz filevi .xyz and look into what is the content of the fileps -ef | grep usernamekill -9 job_ids - where job_ids is the value of the 2nd column of corresponding error caused content in the 8th columnI use fuser for this kind of thing. It will list which process is using a file or files within a mount.
fuser helps only in the specific case when you want to unmount a filesystem. Here the problem is to find what's using a specific file.
Apr 13, 2011 at 19:09
fuser doesn't help here because the problem is to find all the open files in a directory tree. You can tell lsof to show all files and filter, or make it recurse; fuser has no such mode and needs to be invoked on every file.
Apr 14, 2011 at 7:57
fuser works will lists. Try fuser /var/log/*, if any logs are open it will tell which ones and who has it open. If a simple wildcard, won't work, find with or without xargs will do the job.
lsof was not in my path while fuser was, allowing me to find the offending process ID to kill, so +1+thanks.
Oct 13, 2015 at 19:48
I experience this frequently on servers that have NFS network file systems. I am assuming it has something to do with the filesystem, since the files are typically named like .nfs000000123089abcxyz.
My typical solution is to rename or move the parent directory of the file, then come back later in a day or two and the file will have been removed automatically, at which point I am free to delete the directory.
This typically happens in directories where I am installing or compiling software libraries.
.nfsxxx files dropped seemingly in random places. However, I am not sure how this suggestion can make sense - obviously renaming the parent directory does not work because its contents are locked. Wouldn't get the error in the first instance otherwise. I tried it and simply nothing happens, the renaming refuses to happen. Do you want to elaborate/have any other suggestion?
Riffing off of Prabhat's question above, I had this issue in macos high sierra when I stranded an encfs process, rebooting solved it, but this
ps -ef | grep name-of-busy-dir
Showed me the process and the PID (column two).
sudo kill -15 pid-here
fixed it.
I had this problem when an automated test created a ramdisk. The commands suggested in the other answers, lsof and fuser, were of no help. After the tests I tried to unmount it and then delete the folder. I was really confused for ages because I couldn't get rid of it -- I kept getting "Device or resource busy"!
By accident I found out how to get rid of a ramdisk. I had to unmount it the same number of times that I had run the mount command, i.e.
sudo umount path
Due to the fact that it was created using automated testing, it got mounted many times, hence why I couldn't get rid of it by simply unmounting it once after the tests. So, after I manually unmounted it lots of times it finally became a regular folder again and I could delete it.
If you have the server accessible, Try
Deleting that dir from the server
Or, do umount and mount again, try umount -l : lazy umount if facing any issue on normal umount.
I too had this problem where
lsof +D path : gives no output
ps -ef : gives no relevant information
rm -rf /... it will happily delete every single file, including /bin/rm.vim unwanted_file, then simply delete the content inside the file in edit mode, this way i release the disk, but the file is still there.