Saltar al contenido

umount: el dispositivo está ocupado. ¿Por qué?

Te doy la bienvenida a proyecto online, aquí encontrarás la resolución de lo que andabas buscando.

Solución:

Parece que la causa de mi problema fue el nfs-kernel-server estaba exportando el directorio. Él nfs-kernel-server probablemente va detrás de los archivos abiertos normales y, por lo tanto, no está en la lista de lsof y fuser.

Cuando detuve el nfs-kernel-server yo podría umount El directorio.

He hecho una página con ejemplos de todas las soluciones hasta ahora aquí: http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html

Para agregar al comentario anterior de BruceCran, la causa de mi manifestación de este problema en este momento fue una duro montaje de bucle invertido. Ya había comprobado la salida de fuser -vm /lsof +D , mount y cat /proc/mountscomprobó si se estaba ejecutando algún servidor nfs-kernel antiguo, desactivó las cuotas, intentó (pero falló) un umount -f y casi me resigné a abandonar el tiempo de actividad de 924 días antes de finalmente verificar la salida de losetup y encontrar dos loopbacks obsoletos configurados pero no montados:

parsley:/mnt# cat /proc/mounts 
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
/dev/mapper/stuff-root / ext3 rw,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
/dev/dm-2 /mnt/big ext3 rw,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user 0 0

entonces

parsley:/mnt# fuser -vm /mnt/big/
parsley:/mnt# lsof +D big
parsley:/mnt# umount -f /mnt/big/
umount2: Device or resource busy
umount: /mnt/big: device is busy
umount2: Device or resource busy
umount: /mnt/big: device is busy

parsley:/mnt# losetup -a    
/dev/loop0: [fd02]:59 (/mnt/big/dot-dropbox.ext2)
/dev/loop1: [fd02]:59 (/mnt/big/dot-dropbox.ext2)

parsley:/mnt# losetup -d /dev/loop0
parsley:/mnt# losetup -d /dev/loop1
parsley:/mnt# losetup -a
parsley:/mnt# umount big/
parsley:/mnt#

Una publicación en el foro de Gentoo también enumera los archivos de intercambio como posibles culpables; aunque el intercambio de archivos es probablemente bastante raro en estos días, no está de más comprobar la salida de cat /proc/swaps. No estoy seguro de si las cuotas podrían alguna vez evitar un desmontaje: me estaba agarrando a un clavo ardiendo.

En lugar de usar lsof para rastrear el sistema de archivos, simplemente use la lista total de archivos abiertos y grep. Encuentro que estos retornos deben ser más rápidos, aunque son menos precisos. Debería hacer el trabajo.

lsof | grep '/path'

Comentarios y valoraciones

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)


Tags : /

Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *