rmdir failed because of "Device or resource busy"

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.

1. un-mount path

   sudo umount /your_path
   

2. remove mout path in /etc/fstab

   sudo nano /etc/fstab
   

3. reboot

   sudo reboot
   

4. remove directory

   sudo rm -rf /your_path
   

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

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.)