Corrigindo erros "Read-only file system" - Remount e fsck

2026-06-05 Tempo de leitura: Cerca de 11 min Dificuldade: Intermediário

O que "Read-only file system" realmente significa?

Conclusão: Gravações são rejeitadas com Read-only file system (EROFS). Ou a montagem é intencionalmente ro, ou o kernel detectou erros de I/O e rebaixou o filesystem para somente leitura como proteção.

Salvar no vi, um touch ou uma gravação de log falha assim:

touch: cannot touch '/var/log/app.log': Read-only file system

Há três causas amplas. Faça a triagem nesta ordem de prioridade.

• A. Kernel rebaixou para ro por erro (mais importante) -- o padrão do ext4 errors=remount-ro automaticamente muda o filesystem para somente leitura quando detecta erros de I/O ou corrupção de metadados, como proteção
• B. Montagem ro intencional -- uma entrada ro em /etc/fstab, um CD-ROM/SquashFS, ou um volume de container somente leitura
• C. Corrupção do filesystem -- inconsistências que precisam de fsck; geralmente aparece via A

Como verificar o estado atual?

Conclusão: Confirme que o alvo está realmente ro com findmnt, depois use dmesg para identificar por que ficou ro -- um erro de I/O, corrupção de metadados, ou apenas configuração. Nunca grave de volta antes de saber a causa.

1. Confirmar que está realmente em somente leitura

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /

TARGET SOURCE    FSTYPE OPTIONS
/      /dev/sda1 ext4   ro,relatime,errors=remount-ro

Se OPTIONS começa com ro, está em somente leitura. Você também pode ler /proc/mounts diretamente.

grep ' / ' /proc/mounts

2. Descobrir o motivo com dmesg

Este é o coração da triagem. Se erros de I/O de hardware aparecem aqui, isso determina seu próximo passo.

dmesg -T | grep -iE 'ext4-fs|i/o error|remount|read-only|critical'

[Thu Jun  5 09:12:44 2026] EXT4-fs error (device sda1): ext4_journal_check_start:84: Detected aborted journal
[Thu Jun  5 09:12:44 2026] EXT4-fs (sda1): Remounting filesystem read-only
[Thu Jun  5 09:12:43 2026] blk_update_request: I/O error, dev sda, sector 12869632

• I/O error / blk_update_request presente -> suspeitar de falha de disco (abaixo)
• Apenas EXT4-fs error, sem erro de I/O de hardware -> corrupção; fsck necessário (abaixo)
• Nada aparece -> ro por configuração; verifique /etc/fstab

Como voltar para leitura-gravação? (remount)

Conclusão: Para casos de configuração ou transitórios leves, mount -o remount,rw / restaura imediatamente. Mas quando a causa é um erro de I/O ou corrupção, gravar de volta é perigoso -- faça isso apenas após a verificação do dmesg.

Execute isso apenas depois de confirmar que a causa é uma entrada ro no fstab ou um transitório sem erros de I/O.

sudo mount -o remount,rw /

Para uma partição específica, nomeie o alvo explicitamente.

sudo mount -o remount,rw /var

Em caso de sucesso, as OPTIONS do findmnt mudam para rw. Se remount,rw falhar com EROFS ou cannot remount ... read-write, isso é sinal de erro de I/O ou corrupção subjacente -- não tente novamente cegamente; prossiga para diagnóstico de fsck/disco.

Como reparar um filesystem corrompido? (fsck)

Conclusão: Execute fsck apenas quando o filesystem estiver desmontado. Executar fsck em um filesystem montado piora o dano. Repare root a partir de um Live USB ou modo de recuperação.

Por que você não deve executar fsck em um filesystem montado

O fsck reescreve blocos diretamente. Reescrever um filesystem montado (especialmente rw) por baixo do kernel dessincroniza do cache de páginas e destrói dados. É desaconselhado mesmo quando montado ro. Sempre desmonte, ou faça boot do root a partir de um ambiente separado.

Partições não-root

sudo umount /dev/sdb1
sudo fsck -y /dev/sdb1

• -y: responder sim automaticamente (evita uma enxurrada de prompts)
• -f: forçar verificação mesmo se marcado como limpo
• para ext4, isso invoca fsck.ext4 (= e2fsck)

O filesystem root

Root não pode ser desmontado enquanto em execução. Repare de uma das duas formas.

1. Boot a partir de um Live USB / midia de recuperação -> execute fsck -y /dev/sda1 com root desmontado
2. Agendar um fsck automático no próximo boot e reiniciar

# Forcar fsck no proximo boot (systemd): passe como parametro do kernel
# fsck.mode=force
# Inspecionar o agendamento baseado em contagem de montagens
sudo tune2fs -l /dev/sda1 | grep -i 'mount count'

Após o reparo, verifique que você consegue montar e gravar.

sudo mount /dev/sdb1 /mnt && touch /mnt/.write-test && rm /mnt/.write-test

Quando suspeitar de falha de disco?

Conclusão: Se o dmesg mostra I/O error ou números de setor, falha física é provável. Verifique a saúde com smartctl, e se o disco estiver degradando, priorize a evacuação de dados sobre o fsck.

Se você observou erros de I/O de hardware no dmesg, verifique a saúde do disco antes de reparar qualquer coisa.

sudo smartctl -a /dev/sda | grep -iE 'health|reallocated|pending|uncorrect'

SMART overall-health self-assessment test result: FAILED!
  5 Reallocated_Sector_Ct   0x0033   100   100   010    -   384
197 Current_Pending_Sector  0x0012   100   100   000    -   16

• FAILED, ou Reallocated_Sector_Ct / Current_Pending_Sector crescentes -> degradação física; fsck é apenas um paliativo
• Neste estágio, qualquer gravação (incluindo as gravações de reparo do fsck) pode ser o golpe final. Faça backup em somente leitura com dd/rsync primeiro.

Como prevenir recorrência?

Conclusão: errors=remount-ro é um design de segurança que expõe falhas em vez de escondê-las. Mantenha-o, e adicione monitoramento SMART mais monitoramento de espaço livre/inodes para detectar problemas antes de ficar ro.

• Mantenha errors=remount-ro: o padrão do ext4. Enfraquecer para errors=continue esconde corrupção e amplia o dano
• Monitore com smartd (smartmontools): receba alertas sobre contagens crescentes de setores defeituosos antes de ficar ro
• Monitore capacidade e esgotamento de inodes: falhas de gravação por esgotamento são um problema diferente -- veja Investigando No space left on device e Lidando com esgotamento de inodes
• fsck periódico: defina uma verificação automática baseada em contagem de montagens com tune2fs -c <N>