Corrigindo "device is busy" no umount

2026-06-06 Tempo de leitura: Cerca de 11 min Dificuldade: Intermediario

O que "device is busy" realmente significa?

Conclusao: Algo ainda esta usando o filesystem que voce esta tentando desmontar - um processo, uma montagem empilhada ou swap. O kernel retorna EBUSY e recusa o umount. O primeiro passo e encontrar o que esta segurando, nao forcar.

Uma falha tipica se parece com isto:

umount: /mnt/data: target is busy.

Em distribuicoes mais antigas ou algumas ferramentas, a mesma condicao aparece como device is busy ou device or resource busy (o errno EBUSY). A redacao difere, mas a causa e identica: algo ainda referencia o alvo.

Os mantenedores se dividem em alguns grupos. Faca a triagem nesta ordem:

A. Um processo tem um arquivo aberto (mais comum) - um arquivo aberto sob a montagem, um binario em execucao, um log sendo escrito
B. Um diretorio atual dentro da montagem - um shell ou daemon cujo cwd esta sob /mnt/data
C. Uma montagem aninhada - um bind mount ou overlay empilhado sobre ela
D. Usado como swap / loop - o dispositivo serve de base para swap ou um loop device

device is busy e Read-only file system sao problemas diferentes. O primeiro significa "em uso, nao pode desconectar"; o segundo significa "escritas estao bloqueadas". Nao confunda as mensagens. Para read-only, veja Corrigindo "Read-only file system".

Como encontrar o que esta segurando a montagem?

Conclusao: Comece com fuser -vm <ponto-de-montagem> para listar cada processo usando aquele filesystem. A coluna ACCESS distingue arquivo aberto (f), diretorio atual (c), binario em execucao (e) e mmap (m). Use lsof para detalhes por arquivo.

Varredura por montagem com fuser

-m trata o argumento como ponto de montagem (ou dispositivo de bloco) e retorna cada processo usando aquele filesystem. -v adiciona detalhes.

fuser -vm /mnt/data

                     USER        PID ACCESS COMMAND
/mnt/data:           root     kernel mount /mnt/data
                     alice       2314 ..c.. bash
                     alice       2890 F.... tail

Leia a coluna ACCESS - ela e a resposta direta para "por que esta busy?"

c ... o diretorio atual do processo esta sob a montagem (padrao B)
e ... um binario sob a montagem esta executando
f ... um arquivo esta aberto (maiusculo F significa aberto para escrita)
r ... usado como diretorio raiz
m ... um arquivo esta em mmap (bibliotecas compartilhadas, etc.)

No exemplo acima, bash (cwd dentro) e tail (arquivo aberto) sao os mantenedores.

Detalhar arquivos individuais com lsof

Para saber exatamente qual arquivo esta mantido, use lsof. Use +D para recursao sob um ponto de montagem, ou +f -- para consultar por dispositivo.

# Arquivos abertos sob o ponto de montagem
lsof +D /mnt/data

# Por dispositivo de bloco (util quando o caminho do ponto de montagem esta quebrado)
lsof +f -- /dev/sdb1

lsof +D faz stat de toda a arvore e e lento em diretorios grandes. Na pratica, execute fuser -vm primeiro para encontrar a causa, depois use lsof para detalhes.

Como parar os mantenedores e desmontar?

Conclusao: Encerre os mantenedores graciosamente primeiro (saia do diretorio / pare o servico / SIGTERM), depois faca umount. Se persistirem, fuser -k mata forcadamente - mas SIGKILL arrisca perda de dados, entao mantenha como ultimo recurso.

1. A ordem segura: sair ou parar de forma limpa

Se e apenas o cwd do seu proprio shell, saia:

cd /

Se um servico esta segurando, pare o servico (mais confiavel e seguro que kill):

sudo systemctl stop myapp.service

Para processos individuais, encontre o PID e comece com um sinal gentil:

kill 2890        # SIGTERM (permite limpeza)

2. Ultimo recurso: fuser -k para matar em massa

Processos que nao encerram de forma limpa podem ser mortos juntos com fuser -k. Mas -k envia SIGKILL por padrao, o que pode corromper dados no meio de uma escrita.

# Confirmar primeiro (-i pede confirmacao por processo)
sudo fuser -kim /mnt/data

/mnt/data:            2890c  2314c
Kill process 2890 ? (y/N) y

-k ... envia um sinal aos mantenedores (padrao SIGKILL)
-i ... confirma cada um (fortemente recomendado)
-m ... por montagem

Executar fuser -km / contra o root ou um filesystem critico ativo mata com SIGKILL todos os processos do sistema e derruba o servidor. Confira o caminho e sempre use -i em producao. SIGKILL encerra processos sem fazer flush dos buffers de escrita, o que pode corromper dados de banco de dados ou logs.

Depois que os mantenedores forem liberados, desmonte novamente:

sudo umount /mnt/data

Devo usar lazy ou force umount?

Conclusao: Para desconectar imediatamente da arvore, use umount -l (lazy). Para uma montagem NFS sem resposta, use umount -f (force). Ambos sao workarounds que nao resolvem o mantenedor, entao nao confie neles rotineiramente.

Lazy umount (`-l`)

Desconecta o filesystem da arvore imediatamente e limpa quando as referencias desaparecem. Uma saida de emergencia quando voce nao pode (ou nao quer) matar os mantenedores.

sudo umount -l /mnt/data

Ressalvas:

O ponto de montagem desaparece, mas FDs abertos continuam ativos (processos continuam segurando os arquivos antigos). A liberacao completa acontece apenas apos eles encerrarem.
Remontar o mesmo dispositivo imediatamente pode conflitar com referencias persistentes.
Nao garante que dados nao escritos sejam flushed. Em filesystems criticos, corrija a causa primeiro.

Force umount (`-f`)

Principalmente para uma montagem NFS sem resposta - desconecta forcadamente uma montagem travada cujo servidor esta fora.

sudo umount -f /mnt/nfs

Em ext4/xfs local, -f raramente ajuda (a causa busy e um processo local). Para travamentos NFS, leia tambem Corrigindo "Stale file handle" em NFS.

E se esta busy mas nenhum processo aparece?

Conclusao: Se fuser/lsof nao mostram nada mas ainda esta busy, a causa nao e um arquivo aberto. Verifique quatro coisas na ordem: montagens aninhadas, swap, loop devices e exports NFS.

1. Verificar montagens aninhadas (bind / overlay)

Se outra montagem esta empilhada em cima, a pai continua busy. Inspecione a arvore com findmnt -R e desmonte os filhos primeiro.

findmnt -R /mnt/data

TARGET            SOURCE    FSTYPE OPTIONS
/mnt/data         /dev/sdb1 ext4   rw,relatime
+-/mnt/data/cache tmpfs     tmpfs  rw

Aqui, desmonte o filho /mnt/data/cache primeiro. Comum com overlays Docker e mount --bind.

2. Esta sendo usado como swap?

Se a particao serve de base para swap, obviamente voce nao pode desmonta-la. Verifique com swapon --show e execute swapoff.

swapon --show
sudo swapoff /dev/sdb2

3. Um loop device esta segurando?

Se voce montou uma imagem via loop, uma referencia pelo loop device permanece. Verifique com losetup -a e desconecte.

losetup -a
sudo losetup -d /dev/loop0

4. Esta exportado via NFS?

Se o filesystem esta exportado por um servidor NFS, ele continua busy. Libere exports com exportfs.

sudo exportfs -ua          # temporariamente desexportar tudo

Caminho mais rapido: (1) fuser -vm /mnt/data para ver quem segura -> (2) encerrar graciosamente (cd / systemctl stop / kill) -> (3) umount novamente -> se persistir (4) verificar causas nao-processo com findmnt -R, swapon --show, losetup -a -> (5) somente em emergencias, umount -l. Nunca pule a identificacao da causa - essa e a unica regra que previne acidentes.