VPS virou sistema de arquivos somente leitura (2026): diagnóstico de read-only file system, fsck e emergency mode

Primeiro veja o estado de montagem da partição raiz:

findmnt /
mount | grep ' on / '

Se você vir algo como:

/ rw,relatime,...

significa que a partição raiz ainda está em leitura-gravação. Nesse caso, não conseguir gravar arquivos pode ser devido a disco cheio, inodes esgotados, permissões de diretório, cotas ou problemas da própria aplicação.

Se você vir:

/ ro,relatime,...

Aqui ro significa read-only, e a partição raiz já foi montada como somente leitura. Neste momento, não trate o problema como um erro de permissão comum.

Também verifique espaço e inodes:

df -h
df -i

Se o espaço estiver cheio, você pode ler primeiro: O que fazer quando o disco do VPS está cheio? Limpeza de disco + expansão. Se ainda houver espaço mas os inodes estiverem esgotados, leia isto: O VPS mostra espaço em disco disponível mas não consegue gravar arquivos: diagnóstico de esgotamento de inodes.

Quando o sistema de arquivos vira somente leitura, os logs da aplicação muitas vezes só dizem "falha na gravação"; a causa real está nos logs do kernel.

dmesg -T | tail -n 100
journalctl -k --since "2 hours ago"

Procure estas palavras-chave:

EXT4-fs error
Buffer I/O error
blk_update_request
I/O error
Remounting filesystem read-only
XFS ... metadata I/O error

Se aparecer Remounting filesystem read-only, significa que o kernel detectou uma anomalia no sistema de arquivos ou no dispositivo de bloco e o remontou como somente leitura de forma proativa.

Se você não tem familiaridade com diagnóstico de logs, pode consultar primeiro: Como ler os logs do VPS: journalctl, systemctl, Nginx, logs de aplicação.

Muitos tutoriais dão diretamente:

sudo mount -o remount,rw /

Esse comando não é inutilizável, mas não pode ser o primeiro passo.

Se for apenas uma anomalia temporária de parâmetro de montagem, o remount pode restaurar a gravação; mas se o disco subjacente ou o sistema de arquivos já reportou erros, forçar a gravação pode ampliar a corrupção. Uma ordem mais segura é:

1. Verifique se dmesg / journalctl -k tem erros de E/S ou do sistema de arquivos.
2. Faça primeiro backup dos dados importantes que ainda podem ser lidos.
3. Determine se é necessário entrar no modo de resgate para executar fsck.
4. Monte em leitura-gravação após o reparo.

Somente quando os logs não mostrarem erros evidentes de disco/sistema de arquivos e você confirmar que o risco é controlável, tente:

sudo mount -o remount,rw /

Se o comando falhar, anote o erro e não o execute repetidamente.

Às vezes o estado somente leitura é na verdade uma oportunidade: o sistema temporariamente não consegue gravar, mas ainda consegue ler. Tire primeiro os dados-chave.

Priorize o backup de:

• Dumps de banco de dados ou diretórios de dados
• /var/www, diretórios de upload da aplicação
• /etc/nginx, /etc/systemd/system, configurações da aplicação
• .env, chaves, certificados
• Logs recentes e capturas de tela do diagnóstico

Se a máquina ainda consegue se conectar à rede, você pode extraí-los com rsync:

rsync -aHAX --numeric-ids /var/www/ user@backup-server:/backup/vps-www/

Se a rede estiver instável, primeiro compacte os diretórios-chave em outro disco de dados montado corretamente, ou use snapshots do painel/snapshots do disco em nuvem. Para estratégias de backup, você pode consultar: Soluções de backup automático para VPS.

Uma causa muito comum de entrar em emergency mode após reiniciar é um /etc/fstab mal configurado:

• Foi escrito um UUID inexistente.
• Foi montado um disco em nuvem que já foi excluído.
• O tipo de sistema de arquivos está errado.
• Falha na montagem de disco de rede ou armazenamento de objetos, mas não há nofail.
• Após adicionar manualmente um disco de dados, a ordem de inicialização fica instável.

Ver fstab:

cat /etc/fstab
blkid
lsblk -f

Se você descobrir que o UUID de uma partição não raiz não existe, pode comentar temporariamente essa linha e depois reiniciar para verificar.

Para discos de dados não críticos, recomenda-se adicionar nofail para evitar que a falha de montagem de um disco adicional bloqueie todo o VPS em emergency mode:

UUID=xxxx /data ext4 defaults,nofail 0 2

Não adicione nofail à partição raiz sem cuidado. Se a partição raiz não puder ser montada, ela deve parar e ser tratada de qualquer forma.

Se a partição raiz já reportou erros de ext4, normalmente é necessário fsck. Mas executar fsck diretamente em uma partição raiz montada é uma operação perigosa.

Uma abordagem mais segura:

1. Entre no modo de resgate / modo de recuperação fornecido pelo seu provedor de VPS.
2. Encontre o nome do dispositivo da partição raiz.
3. Confirme que ela não está montada.
4. Execute fsck.

Ver partições:

lsblk -f
blkid

Supondo que a partição raiz seja /dev/vda1:

sudo fsck -f /dev/vda1

Se for XFS, você não pode usar o método de reparo fsck do ext4:

sudo xfs_repair /dev/vda1

Observação: nos ambientes de resgate de diferentes provedores, o nome do dispositivo pode mudar de /dev/vda1 para /dev/sda1 ou /dev/nvme0n1p1. Sempre se baseie em lsblk -f, e não copie o nome de dispositivo de outra pessoa.

Se os logs contiverem muitos erros de E/S, por exemplo:

Buffer I/O error on dev vda
blk_update_request: I/O error

Isso não é necessariamente uma configuração incorreta no seu sistema; também pode ser:

• Anomalia subjacente do disco em nuvem
• Instabilidade do armazenamento do host
• Falha do nó do VPS
• Sobre-venda causando anomalias de E/S prolongadas
• Disco em nuvem migrado ou com velocidade limitada pelo provedor

Nesse caso, guarde os logs e abra um ticket o quanto antes. No ticket, não escreva apenas "a máquina quebrou"; é melhor incluir:

dmesg -T | tail -n 100
journalctl -k --since "6 hours ago"
lsblk -f
findmnt /

Se você suspeitar de contenção de recursos de vizinhos ou instabilidade do disco, pode comparar com: Como julgar sobre-venda de VPS: roubo de CPU, instabilidade do disco, vizinhos disputando recursos.

Após concluir o fsck ou xfs_repair, monte e verifique primeiro:

sudo mount /dev/vda1 /mnt
ls /mnt

Fique atento a:

• Se /mnt/lost+found tem uma grande quantidade de arquivos
• Se o diretório do banco de dados está completo
• Se o diretório de upload da aplicação está completo
• Se /etc/fstab foi corrigido
• Se ainda há novos erros de E/S nos logs

Se conseguir iniciar normalmente, também não devolva o tráfego imediatamente. Verifique primeiro os serviços:

systemctl --failed
journalctl -p err -b

Tenha cuidado especial com serviços de banco de dados. Se serviços como MySQL, PostgreSQL e Redis foram interrompidos à força durante a anomalia do sistema de arquivos, eles também podem precisar de suas próprias verificações de consistência de dados.

Nas seguintes situações, não se recomenda continuar forçando o reparo no disco original:

• dmesg exibe erros de E/S continuamente.
• Volta a ficar somente leitura logo após o reparo com fsck.
• Arquivos-chave do banco de dados estão corrompidos e não há verificação confiável.
• O provedor confirma uma anomalia no nó de armazenamento.
• Esta máquina já entrou em emergency mode várias vezes.

Neste ponto, uma rota mais segura é:

1. Restaurar a partir de snapshot ou backup para um novo VPS.
2. Verificar os dados do serviço.
3. Trocar o DNS ou a entrada do proxy reverso.
4. Manter a máquina antiga em estado somente leitura para recuperar dados adicionais.

Para ideias de migração, você pode consultar: Guia de migração de VPS: como reduzir o tempo de inatividade ao trocar de provedor/centro de dados.

Ao encontrar read-only file system ou emergency mode, proceda nesta ordem:

1. findmnt / verifique se a partição raiz está ro.
2. df -h e df -i para descartar espaço cheio e esgotamento de inodes.
3. dmesg -T / journalctl -k para encontrar erros do sistema de arquivos e de E/S.
4. Faça backup dos diretórios-chave primeiro quando os dados forem legíveis.
5. Verifique se /etc/fstab, blkid, lsblk -f coincidem.
6. Não execute fsck diretamente em uma partição raiz montada.
7. Entre no modo de resgate e execute fsck ou xfs_repair na partição não montada.
8. Após o reparo, verifique systemctl --failed e os logs de erro.
9. Se os erros de E/S persistirem, priorize a migração; não continue apostando no disco original.

Um VPS virar um sistema de arquivos somente leitura não é um simples "permissões insuficientes". Muitas vezes é o sistema protegendo os dados: ou o disco/sistema de arquivos apresentou erro, ou a configuração de montagem na inicialização está inconsistente, ou o disco em nuvem subjacente já ficou instável.

A ordem correta de tratamento é: veja primeiro os logs e o estado de montagem, faça backup primeiro se for legível, depois corrija o fstab ou entre no modo de resgate para fazer uma verificação do sistema de arquivos. Recuperar é bom, mas enquanto os erros de E/S continuarem aparecendo, não continue apostando o seu serviço no disco original; migre para uma nova máquina o quanto antes.