rmdir falló debido a dispositivo o recurso ocupado

Enfrenté un problema como este porque monté una carpeta compartida en VM y quiero eliminar el directorio después de desmontarlo y solo quiero compartir mi solución.

1. ruta de desmontaje

   sudo umount /your_path
   

2. elimine la ruta de mout en /etc/fstab

   sudo nano /etc/fstab
   

3. reiniciar

   sudo reboot
   

4. eliminar directorio

   sudo rm -rf /your_path
   

Gracias por la respuesta de @g-v. Pero encontré que el resultado es otro problema. Usamos el indicador CLONE_NEWNS cuando bifurcamos un proceso. Se pueden encontrar más detalles en el indicador CLONE_NEWNS y MESOS-3349 Error de dispositivo ocupado

En pocas palabras, montamos en el proceso principal. Y luego desmonte en el proceso secundario, debido a CLONE_NEWNS, el punto de montaje aún existe que maneja el proceso principal. Entonces, cuando llame a rmdir, obtendrá el código de error EBUSY.

Para evitar los problemas anteriores, podríamos usar el montaje compartido o el montaje esclavo. Se pueden encontrar más detalles en LWN 159092

Según mi experiencia, las siguientes operaciones son asíncronas en Linux:

• Archivo de cierre. Inmediatamente después de close() devuelve, umount() puede devolver EBUSY mientras realiza la liberación asíncrona. Ver discusión aquí:página 1, página 2.
• Desmontaje del sistema de archivos. El dispositivo montado puede estar ocupado hasta que todos los datos se escriban en el disco.

Incluso yo llamo sync && echo 2 > /proc/sys/vm/drop_caches e intente colocar cachés de archivos, todavía no funciona.

Ver sync(8) :

En Linux, sync solo se garantiza programar los bloques sucios para escribir; en realidad, puede tomar un poco de tiempo antes de que finalmente se escriban todos los bloques. El reboot(8) y halt(8) los comandos tienen esto en cuenta durmiendo durante unos segundos después de llamar a sync(2) .

En cuanto a /proc/sys/vm/drop_caches , ver aquí:

Esta es una operación no destructiva y no liberará ningún objeto sucio.

Por lo tanto, inmediatamente después de su comando, es posible que los datos aún estén en cola para escritura y que el desmontaje aún no haya terminado.

Actualizar

Sin embargo, cuando el desmontaje asíncrono está en acción, el núcleo devolverá EBUSY para operaciones en dispositivo montado , pero no para punto de montaje .

Entonces los casos anteriores no pudieron ser la razon de tu problema :P

PD.

En realidad, no entiendo por qué la página del manual dice que sync(8) no es síncrono en Linux. Llama sync(2) que dice:

Según la especificación estándar (por ejemplo, POSIX.1-2001), sync() programa las escrituras, pero puede regresar antes de que se complete la escritura real. Sin embargo, desde la versión 1.3.20 Linux realmente espera. (Esto aún no garantiza la integridad de los datos:los discos modernos tienen grandes cachés).