rmdir failed because of "Device or resource busy"

Question

there are a lot of similar problem like "Device or resource busy". But I think my problem is different with them.

I use mount --bind to bind a directory

mount --bind /tmp/origin /tmp/mount

and then could umount successfully

umount /tmp/mount

And then if I call rm at once

rm -rf /tmp/mount

I could get a error Device or resource busy. If I wait 2~3 seconds, and then call rm, it could success.

So this behaviour is very strange here. I try use

lsof +D /tmp/mount

could not see anything.

I also use fuser -vm /tmp/mount, could not see any process hold this folder.

I compare the /proc/mounts before umount /tmp/mount and after umount /tmp/mount. /tmp/mount has already removed.

I compare the stat /proc/mounts before umount /tmp/mount and after umount /tmp/mount. The inode also different, this means /tmp/mount has already removed complete.

Even I call sync && echo 2 > /proc/sys/vm/drop_caches and try to drop file caches, it still not work.

I try this in both Ubuntu 14.04 and CentOS 6.6. They have same results.

That's a great question. I'd give it an upvote but it's more a general computing question than it is programming-related so it’s *off-topic* for StackOverflow. It would be much more appropriate for [Unix and Linux](http://unix.stackexchange.com/) or even [Super User](http://superuser.com/). — Anthony Geoghegan, Sep 06 '15 at 17:40
No problem. If I was you, I'd copy and paste the content of this question into the new one and then delete this version to avoid the new question being flagged as a cross-post. Welcome to Stack Exchange! — Anthony Geoghegan, Sep 06 '15 at 21:30
Because the above commands are happends in code, not from shell. The the reason of this problem is related to this params when call clone a process: CLONE_NEWNS. So I still keep it here. — haosdent, Sep 10 '15 at 10:44
That makes sense. BTW, I upvoted g-v’s answer as it provided useful relevant information. Even though your particular problem was caused by a different issue, I’d suggest upvoting their answer if it helped you debug your problem. — Anthony Geoghegan, Sep 10 '15 at 13:15

score 12 · Answer 1 · answered Jul 28 '16 at 15:43

12

I faced problem like this because I mount shared folder in VM and I want to remove directory after unmount and I just want to share my solution.

un-mount path
```
sudo umount /your_path
```
remove mout path in /etc/fstab
```
sudo nano /etc/fstab
```
reboot
```
sudo reboot
```
remove directory
```
sudo rm -rf /your_path
```

answered Jul 28 '16 at 15:43

thyahan

121
1
4

Actually he could remove the directory 3 seconds later, without rebooting, but thank you anyway for your answer, that could help someone else. – Gar Jul 28 '16 at 16:04
2

`umount /path -l` forces unmount – xdevs23 Oct 18 '16 at 12:44

gavv · Answer 2 · 2015-09-25T18:58:16.157

In my experience, the following operations are asynchronous on Linux:

Closing file. Immediately after close() returns, umount() may return EBUSY while it performs asynchronous release. See discussion here: page 1, page 2.
Umounting filesystem. Mounted device may be busy until all data is written to disk.

Even I call sync && echo 2 > /proc/sys/vm/drop_caches and try to drop file caches, it still not work.

See sync(8):

On Linux, sync is only guaranteed to schedule the dirty blocks for writing; it can actually take a short time before all the blocks are finally written. The reboot(8) and halt(8) commands take this into account by sleeping for a few seconds after calling sync(2).

As for /proc/sys/vm/drop_caches, see here:

This is a non-destructive operation and will not free any dirty objects.

Thus, immediately after your command, data may be still queued for write and umounting is not yet finished.

Update

However, when asynchronous umounting is in action, kernel will return EBUSY for operations on mounted device, but not for mount point.

So the cases above could not be the reason of your problem :P

PS.

Actually I don't understand why the man page states that sync(8) is not synchronous in Linux. It calls sync(2) which states:

According to the standard specification (e.g., POSIX.1-2001), sync() schedules the writes, but may return before the actual writing is done. However, since version 1.3.20 Linux does actually wait. (This still does not guarantee data integrity: modern disks have large caches.)

Nice ideas but none of them solve the issue on my end. looks like a flaw in the mount implementation — John, Jan 10 '20 at 20:43

score 2 · Accepted Answer · edited May 23 '17 at 12:09

Thank you for @g-v answer. But I found the result is another problem. We use CLONE_NEWNS flag when fork a process. More details could be found in CLONE_NEWNS flag and MESOS-3349 Device busy bug

In a short word, we mount in parent process. And then umount in child process, because of CLONE_NEWNS, the mount point still exists which handled by parent process. So when call rmdir would got EBUSY error code.

To avoid above problems, we could use shared mount or slave mount. More details could be found in LWN 159092

score -1 · Answer 4 · edited Jan 06 '17 at 06:10

-1

check
```
df -h
```
then
```
sudo umount /path
```

edited Jan 06 '17 at 06:10

Deepak Mahakale

22,834
10
68
88

answered Jan 05 '17 at 22:13

user1766756

24
2

2

This does not appear to answer the question. – clearlight Jan 06 '17 at 06:05

score -2 · Answer 5 · edited Jun 17 '20 at 09:57

-2

Follow these steps:

open Resource Monitor
click on "associated handles" drop box
search the folder creating problem
Right click on each process and "End process".

Now you can delete the folder

edited Jun 17 '20 at 09:57

Roberto Caboni

7,252
10
25
39

answered Jun 17 '20 at 08:35

LST

43
7

rmdir failed because of "Device or resource busy"

5 Answers5