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

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

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

Conclusao: Gravacoes sao rejeitadas com Read-only file system (EROFS). Ou a montagem e intencionalmente ro, ou o kernel detectou erros de I/O e rebaixou o filesystem para somente leitura como protecao.

Salvar no vi, um touch ou uma gravacao de log falha assim:

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

Ha tres causas amplas. Faca a triagem nesta ordem de prioridade.

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

Como verificar o estado atual?

Conclusao: Confirme que o alvo esta realmente ro com findmnt, depois use dmesg para identificar por que ficou ro -- um erro de I/O, corrupcao de metadados, ou apenas configuracao. Nunca grave de volta antes de saber a causa.

1. Confirmar que esta realmente em somente leitura

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /

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

Se OPTIONS comeca com ro, esta em somente leitura. Voce tambem pode ler /proc/mounts diretamente.

grep ' / ' /proc/mounts

2. Descobrir o motivo com dmesg

Este e o coracao da triagem. Se erros de I/O de hardware aparecem aqui, isso determina seu proximo 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 -> corrupcao; fsck necessario (abaixo)
• Nada aparece -> ro por configuracao; verifique /etc/fstab

Como voltar para leitura-gravacao? (remount)

Conclusao: Para casos de configuracao ou transitorios leves, mount -o remount,rw / restaura imediatamente. Mas quando a causa e um erro de I/O ou corrupcao, gravar de volta e perigoso -- faca isso apenas apos a verificacao do dmesg.

Execute isso apenas depois de confirmar que a causa e uma entrada ro no fstab ou um transitorio sem erros de I/O.

sudo mount -o remount,rw /

Para uma particao especifica, 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 e sinal de erro de I/O ou corrupcao subjacente -- nao tente novamente cegamente; prossiga para diagnostico de fsck/disco.

Como reparar um filesystem corrompido? (fsck)

Conclusao: 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 recuperacao.

Por que voce nao 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 paginas e destroi dados. E desaconselhado mesmo quando montado ro. Sempre desmonte, ou faca boot do root a partir de um ambiente separado.

Particoes nao-root

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

• -y: responder sim automaticamente (evita uma enxurrada de prompts)
• -f: forcar verificacao mesmo se marcado como limpo
• para ext4, isso invoca fsck.ext4 (= e2fsck)

O filesystem root

Root nao pode ser desmontado enquanto em execucao. Repare de uma das duas formas.

1. Boot a partir de um Live USB / midia de recuperacao -> execute fsck -y /dev/sda1 com root desmontado
2. Agendar um fsck automatico no proximo 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'

Apos o reparo, verifique que voce consegue montar e gravar.

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

Quando suspeitar de falha de disco?

Conclusao: Se o dmesg mostra I/O error ou numeros de setor, falha fisica e provavel. Verifique a saude com smartctl, e se o disco estiver degradando, priorize a evacuacao de dados sobre o fsck.

Se voce observou erros de I/O de hardware no dmesg, verifique a saude 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 -> degradacao fisica; fsck e apenas um paliativo
• Neste estagio, qualquer gravacao (incluindo as gravacoes de reparo do fsck) pode ser o golpe final. Faca backup em somente leitura com dd/rsync primeiro.

Como prevenir recorrencia?

Conclusao: errors=remount-ro e um design de seguranca que expoe falhas em vez de esconde-las. Mantenha-o, e adicione monitoramento SMART mais monitoramento de espaco livre/inodes para detectar problemas antes de ficar ro.

• Mantenha errors=remount-ro: o padrao do ext4. Enfraquecer para errors=continue esconde corrupcao 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 gravacao por esgotamento sao um problema diferente -- veja Investigando No space left on device e Lidando com esgotamento de inodes
• fsck periodico: defina uma verificacao automatica baseada em contagem de montagens com tune2fs -c <N>