Você abre o painel do NAS, vê os arquivos no lugar, mas nada grava: cópias falham, backups param e a mensagem de erro se repete. Antes de reiniciar o equipamento ou forçar uma remontagem, é preciso entender o que levou o volume do NAS em modo somente leitura a esse estado. Este texto mostra como diagnosticar a causa, separar falha de disco, de rede e de permissão, e agir na ordem certa para preservar os dados.
O que significa um volume de NAS em modo somente leitura
Um volume de NAS em modo somente leitura é um estado de proteção no qual o sistema operacional do storage monta o sistema de arquivos permitindo apenas operações de leitura, bloqueando qualquer tentativa de gravação, modificação, exclusão ou criação de arquivos. Esse mecanismo existe para preservar a integridade dos dados quando o controlador detecta uma condição anômala que poderia corromper o volume se novas escritas fossem aceitas. Em sistemas como ext4, Btrfs, XFS e NTFS — comuns em equipamentos QNAP, Synology, Asustor e TrueNAS — o kernel alterna automaticamente para o modo somente leitura ao identificar inconsistências no journal, erros de metadados ou falhas recorrentes de I/O.
Na prática, o usuário continua enxergando as pastas e abrindo arquivos, mas não consegue salvar alterações, mover itens, criar novas pastas ou gravar backups no volume. O comportamento é diferente de uma simples restrição de permissão de usuário: aqui o bloqueio parte do próprio sistema de arquivos ou do controlador RAID, e não de uma regra de compartilhamento. Essa distinção importa porque tentar contornar o bloqueio alterando permissões, reiniciando o equipamento ou forçando uma remontagem sem diagnóstico prévio pode transformar um problema contornável em perda definitiva de dados.
O modo somente leitura também aparece como resposta a um RAID degradado em situações críticas. Quando um array perde mais discos do que sua paridade suporta — por exemplo, dois discos em um RAID 5 —, o controlador pode montar o volume em modo de emergência para impedir que novas gravações agravem a inconsistência entre os membros. Nesse cenário, o sintoma é o mesmo, mas a causa é estrutural e exige abordagem completamente diferente de um simples erro de sistema de arquivos.
Sintomas: como saber que o volume está montado como somente leitura
O sinal mais direto é a mensagem de erro exibida ao tentar gravar qualquer arquivo no volume. No Windows, ao acessar um compartilhamento SMB somente leitura, o Explorador retorna “Acesso negado” ou “O disco está protegido contra gravação”. Em clientes Linux ou macOS, o erro típico é “Read-only file system” ao executar comandos de cópia, criação de diretório ou edição de arquivo. No painel administrativo do NAS, o volume aparece com status diferente de “Normal” — frequentemente “Somente leitura”, “Read-only” ou “Degradado”.
Outros sintomas acompanham o bloqueio de gravação e ajudam a confirmar a condição:
- Serviços que dependem de escrita param: bancos de dados, máquinas virtuais e backups noturnos falham com erros de I/O.
- Arquivos abertos para edição não salvam, mesmo com permissão de usuário correta.
- O painel do NAS registra alertas de SMART, erros de leitura ou queda de disco no mesmo período.
- Compartilhamentos NFS retornam “Permission denied” mesmo com regras de exportação inalteradas.
- O volume aparece com uso de espaço congelado, sem refletir novas gravações.
Um detalhe que confunde muitos administradores: o modo somente leitura pode ser intermitente no início. O volume monta gravável após o boot, funciona por alguns minutos e volta a cair para somente leitura quando o controlador encontra novos erros de leitura. Esse padrão oscilante é típico de disco com setores defeituosos em progressão ou de RAID com membro prestes a falhar — e é justamente o cenário em que insistir em gravar dados agrava o quadro, porque cada tentativa de escrita força o controlador a tocar em regiões problemáticas do disco.
Causas do volume entrar em modo somente leitura
As causas se dividem em quatro grupos principais: erros de sistema de arquivos, falhas físicas ou de RAID, problemas de permissão e bloqueios impostos pelo próprio firmware do NAS. Cada grupo exige um tipo de intervenção diferente, e o erro mais caro é tratar uma falha física como se fosse um problema lógico de permissão — ou o contrário.
Erros de sistema de arquivos e montagem suja
Um desligamento abrupto — queda de energia, botão power pressionado por muito tempo, falha de fonte — deixa o journal do sistema de arquivos em estado inconsistente. No próximo boot, o kernel detecta a “montagem suja” e, dependendo da gravidade, monta o volume em modo somente leitura para evitar que escritas sobre um journal corrompido destruam metadados. Sistemas como ext4 tentam um replay do journal automaticamente; se o replay falhar, o volume permanece somente leitura até que um fsck seja executado manualmente.
Corrupção de metadados também ocorre sem desligamento brusco: falhas de memória no NAS, bugs de firmware durante atualização, ou um cabo SATA/SAS defeituoso gerando erros intermitentes de comunicação podem corromper estruturas internas do sistema de arquivos. Em Btrfs, o mecanismo de copy-on-write reduz alguns riscos, mas não elimina a possibilidade de árvore de metadados inconsistente quando há falha de hardware subjacente.
Falhas de disco, setores defeituosos e RAID degradado
Quando o controlador encontra erros de leitura persistentes em um membro do RAID, dois caminhos são possíveis: se a paridade ainda permite reconstruir os dados, o array segue funcionando, mas com latência elevada; se os erros ultrapassam a tolerância do nível RAID, o controlador pode colocar o volume em modo de proteção. Em RAID 5, a perda de um disco deixa o array degradado, mas ainda gravável; a perda de dois discos normalmente derruba o volume ou o monta somente leitura.
O estado do SMART é o primeiro indicador a ser verificado. Atributos como Reallocated Sector Count, Current Pending Sector e Uncorrectable Sector Count em elevação indicam disco em falha iminente.
Problemas de permissão, NFS e SMB
Nem todo bloqueio de gravação vem do sistema de arquivos. Em ambientes com Active Directory, LDAP ou permissões locais mal configuradas, o volume em si está gravável, mas o usuário ou grupo perdeu o direito de escrita na pasta raiz do compartilhamento. O sintoma é idêntico ao do modo somente leitura real: o cliente recebe “Acesso negado” ao gravar. A diferença aparece no painel do NAS, que continua exibindo o volume como “Normal”.
Em compartilhamentos NFS, a opção de exportação com ro (read-only) ou a ausência de rw produz o mesmo efeito. Em SMB, políticas de grupo, permissões NTFS conflitantes ou a ativação acidental de “somente leitura” na pasta compartilhada bloqueiam a gravação sem qualquer problema físico. Antes de qualquer intervenção em disco, vale confirmar se o bloqueio não é apenas uma questão de ACL, porque remontar ou recriar um volume saudável por causa de uma permissão mal configurada é um erro evitável e destrutivo.
Proteção contra gravação e bloqueios do próprio NAS
Alguns fabricantes implementam proteção automática contra gravação quando detectam condições de risco. O QNAP, por exemplo, pode colocar um volume em modo somente leitura quando o pool de armazenamento atinge um limite crítico de erros ou quando a bateria do cache de escrita falha. O Synology tem comportamento semelhante em volumes com cache SSD em estado anômalo: para evitar perda de dados em trânsito, o sistema bloqueia novas escritas até que o cache seja desativado ou substituído.
Há também o caso de bloqueio intencional por snapshot cheio. Em volumes com snapshots habilitados e cota de espaço esgotada, o sistema pode recusar novas escritas porque não há espaço para alocar o próximo snapshot. A mensagem no painel geralmente indica “Volume cheio” ou “Snapshot reserve esgotado”, mas o efeito percebido pelo usuário é o mesmo: não consegue gravar. Esse cenário se resolve liberando espaço ou excluindo snapshots antigos — sem tocar em disco ou RAID.
Como diagnosticar o volume antes de tentar qualquer correção
O diagnóstico correto é o que separa uma recuperação simples de uma perda definitiva. A ordem importa: primeiro confirmar o estado físico dos discos e do RAID, depois avaliar o sistema de arquivos, e só então examinar permissões e configurações de compartilhamento. Inverter essa ordem — por exemplo, executar um fsck em um volume cujo disco está fisicamente falhando — pode multiplicar os danos, porque o fsck força leituras e escritas intensivas justamente nas áreas problemáticas.
Verificando logs, SMART e estado do RAID
O primeiro passo é abrir o painel administrativo do NAS e verificar o status do pool de armazenamento e do volume. Procure por alertas de disco, mensagens de I/O error, queda de membro do RAID ou eventos de “read-only remount”. Em seguida, acesse os logs do sistema — em QNAP e Synology, o Centro de Logs registra eventos de disco, RAID e sistema de arquivos com timestamps que permitem correlacionar o início do problema com um evento específico, como um desligamento abrupto ou um pico de erros em um disco.
O SMART de cada disco deve ser lido individualmente. Valores brutos de Current Pending Sector acima de zero, Reallocated Sector Count em crescimento ou Uncorrectable Sector Count positivo indicam falha física em curso. Se o NAS estiver em RAID, confirme o estado do array: “Degradado” significa que um disco caiu e a paridade está sendo usada; “Inativo” ou “Falhou” indica que mais discos caíram do que o nível suporta. Nesse último caso, não tente forçar o array a montar nem execute rebuild — cada operação sobre discos instáveis reduz a chance de recuperação. O artigo sobre RAID com erro de leitura detalha os cuidados nesse cenário.
Confirmando se o problema é no NAS, na rede ou no cliente
Antes de mexer no volume, vale isolar a origem do bloqueio. Teste a gravação a partir de outro cliente: se um segundo computador grava normalmente no mesmo compartilhamento, o problema está na configuração do primeiro cliente, não no NAS. Teste também outro compartilhamento no mesmo NAS: se um volume aceita gravação e outro não, o problema é específico daquele volume; se todos os volumes bloqueiam, a causa pode estar no controlador, no cache ou em uma configuração global.
Verifique o tipo de acesso: um volume montado somente leitura via NFS pode estar perfeitamente gravável via SMB, o que aponta para regra de exportação e não para falha de disco. O mesmo vale para permissões de usuário: tente gravar com a conta de administrador local do NAS. Se o admin grava e o usuário comum não, o problema é de ACL. Se nem o admin grava, o bloqueio está no sistema de arquivos ou no hardware. Essa sequência de isolamento leva poucos minutos e evita intervenções destrutivas desnecessárias.
Como recuperar o acesso de gravação passo a passo
A recuperação do acesso de gravação só deve ser tentada depois de garantir que os dados estão seguros. Isso significa que a primeira ação concreta, antes de qualquer reparo, é copiar o conteúdo do volume para outra mídia. Se o volume está somente leitura, a cópia ainda é possível — e é exatamente essa janela que precisa ser aproveitada. Reparos sem backup prévio são a principal causa de perda definitiva em casos que começaram contornáveis.
Remontagem segura e verificação do sistema de arquivos
Se o diagnóstico apontou apenas erro de sistema de arquivos — sem falha física nos discos e sem RAID degradado —, o caminho é desmontar o volume e executar a verificação do sistema de arquivos apropriada. Em sistemas baseados em Linux, isso significa um fsck (ext4), btrfs check (Btrfs) ou xfs_repair (XFS). O volume precisa estar desmontado para que a verificação seja segura; executar fsck em um volume montado, mesmo que somente leitura, pode corromper ainda mais os metadados.
Depois da verificação e correção, o volume pode ser remontado com permissão de escrita. A remontagem deve ser feita pelo painel do NAS ou por comando explícito, nunca por reinicialização forçada. Se o sistema de arquivos voltar a cair para somente leitura minutos depois da remontagem, o problema não era apenas lógico: há falha de hardware subjacente, e insistir em novas remontagens e verificações só aumenta o desgaste dos discos. Nesse ponto, a prioridade muda de “recuperar o acesso” para “recuperar os dados e substituir o hardware”.
Quando o volume precisa ser recriado ou substituído
Há situações em que o volume não deve ser reparado, e sim substituído. Se o SMART de um ou mais discos mostra falha física em progressão, se o RAID está degradado com erros de leitura persistentes, ou se o sistema de arquivos entra em somente leitura repetidamente após correções, o volume atingiu o fim da vida útil confiável. Recriar o volume sobre os mesmos discos — mesmo que tecnicamente possível — significa confiar dados a um hardware que já demonstrou não merecer confiança.
A decisão entre reparar e substituir considera três fatores: a idade e o estado SMART dos discos, a criticidade dos dados e o custo de uma nova falha. Para ambientes corporativos, a substituição dos discos e a recriação do volume a partir de backup costuma ser mais barata do que uma segunda parada não programada. Para casos sem backup, a ordem é inversa: primeiro recuperar os dados do volume somente leitura, depois substituir o hardware. O artigo sobre RAID com disco caindo explica como priorizar essa sequência.
Como recuperar os dados de um volume somente leitura
A recuperação de dados de um volume somente leitura segue uma lógica própria, diferente da recuperação do acesso de gravação. O objetivo aqui não é fazer o volume voltar a aceitar escrita, e sim extrair o conteúdo antes que a condição piore. Em muitos casos, o volume somente leitura é uma janela de oportunidade: os dados ainda estão acessíveis, e a cópia pode ser feita de forma íntegra se nenhuma intervenção destrutiva for tentada antes.
Cópia dos dados antes de qualquer reparo
A cópia deve ser feita bloco a bloco ou arquivo a arquivo, dependendo do estado do volume. Se o sistema de arquivos ainda monta e a leitura está estável, a cópia arquivo a arquivo para uma mídia externa — outro NAS, um storage USB ou um servidor de destino — é suficiente. Priorize os dados críticos primeiro: bancos de dados, documentos, máquinas virtuais e arquivos sem outra cópia. Não interrompa a cópia para “testar se já voltou a gravar”; cada interrupção e retomada força novas leituras em discos potencialmente instáveis.
Se a leitura apresentar erros intermitentes ou arquivos corrompidos, a cópia arquivo a arquivo pode não ser viável. Nesse cenário, a duplicação setor a setor dos discos — criando imagens forenses de cada membro do RAID — é o procedimento que maximiza a chance de recuperação. A imagem é gerada em hardware controlado, com leitura limitada e registro de setores ilegíveis, e o trabalho de reconstrução lógica é feito sobre as imagens, não sobre os discos originais. Essa abordagem protege a mídia original de desgaste adicional durante as tentativas de recuperação.
Recuperação quando o volume não monta mais
Quando o volume não monta nem em modo somente leitura — o NAS não reconhece o pool, o RAID aparece como inativo ou o sistema de arquivos está severamente corrompido —, a recuperação depende de reconstrução em nível de RAID e sistema de arquivos. O processo exige identificar a ordem correta dos discos, o tamanho de stripe, o algoritmo de paridade e a geometria do array, para então recompor o volume lógico e extrair os arquivos. Em RAID 5 e RAID 6, a paridade precisa ser recalculada para reconstruir os dados dos discos ausentes ou com setores ilegíveis.
Esse tipo de recuperação não é executável com segurança pelo painel do NAS. O próprio ato de recriar o array — mesmo que “sem formatação” — reescreve metadados de RAID e pode inviabilizar a reconstrução posterior. O mesmo vale para a tentativa de forçar a montagem com opções que ignoram erros: o sistema pode montar parcialmente, mas a leitura resultante frequentemente entrega arquivos truncados ou corrompidos. Em casos de RAID com dois discos em falha, o cenário é ainda mais delicado, como detalha o artigo sobre RAID com dois discos com falha.
A recuperação em laboratório segue uma sequência definida: diagnóstico dos discos individuais, clonagem setor a setor em equipamento com controle de leitura, reconstrução do RAID em software especializado, reparo do sistema de arquivos sobre a imagem e extração dos dados para mídia de entrega. Cada etapa é registrada, e os discos originais são preservados intactos. O resultado depende do estado físico dos discos e da extensão da corrupção — não há recuperação garantida quando os setores que continham os dados já não são legíveis.
Como evitar que o volume volte ao modo somente leitura
A prevenção do modo somente leitura passa por duas frentes: monitoramento contínuo que detecta falhas antes de se tornarem críticas, e configurações de energia e atualização que evitam as causas mais comuns de corrupção. Nenhuma medida preventiva elimina o risco de falha física, mas a combinação das duas frentes reduz drasticamente a frequência de incidentes e, principalmente, o impacto quando eles ocorrem.
Rotina de backup e monitoramento preventivo
O backup regular é a única proteção que cobre todos os cenários: falha de disco, corrupção de sistema de arquivos, erro humano, ransomware e falha de controlador. A regra prática é manter três cópias dos dados em duas mídias diferentes, com uma cópia fora do local principal. Para NAS, isso significa backup para outro NAS, para storage em nuvem ou para mídia removível com rotina verificada — backup que nunca foi testado para restauração não é backup, é esperança.
O monitoramento preventivo inclui a leitura programada do SMART de todos os discos, alertas configurados para atributos críticos e revisão periódica dos logs do sistema. Agendar testes de superfície periódicos e scrubbing do RAID também ajuda: o scrubbing força a leitura de todos os blocos e da paridade, identificando setores defeituosos antes que eles se acumulem a ponto de derrubar o volume. Um disco com setores pendentes detectado cedo pode ser substituído de forma planejada, com o array íntegro, em vez de esperar a falha completa no pior momento.
Configurações de energia, desligamento e atualização do NAS
Quedas de energia são uma das principais causas de montagem suja e corrupção de journal. O NAS deve estar ligado a um nobreak com comunicação USB ou rede, configurado para desligar o equipamento de forma ordenada quando a bateria atingir nível crítico. O desligamento ordenado permite que o sistema de arquivos feche o journal corretamente, evitando a necessidade de replay no próximo boot. Em ambientes sem nobreak, mesmo um desligamento único durante escrita intensa pode corromper metadados.
Atualizações de firmware devem ser aplicadas com cautela e fora de janelas críticas. Antes de atualizar, confirme que o backup está íntegro e que o RAID está em estado saudável. Atualizações aplicadas sobre um array já degradado ou com disco em falha podem transformar um problema latente em perda imediata. O mesmo cuidado vale para a substituição de discos: a troca de um membro do RAID força um rebuild que exige leitura intensiva de todos os outros discos — se um segundo disco estiver perto da falha, o rebuild pode derrubá-lo. O artigo sobre trocar o disco errado no RAID mostra como esse cenário se desenrola na prática.
O que define o custo de um serviço de recuperação de NAS
O custo de uma recuperação de dados de NAS não é tabelado, porque cada caso combina variáveis diferentes: nível do RAID, número de discos, estado físico de cada disco, extensão da corrupção lógica e urgência do prazo. Um RAID 1 com um disco íntegro e outro com poucos setores defeituosos exige menos trabalho do que um RAID 6 com quatro discos apresentando falha física simultânea e sistema de arquivos severamente corrompido.
Os fatores que mais pesam no custo são a complexidade da reconstrução do RAID, a necessidade de clonagem em equipamento especializado, o tempo de sala limpa se houver falha mecânica, e a quantidade de dados a ser extraída e validada. Casos que exigem recuperação de emergência — com parada operacional e prazo reduzido — envolvem priorização de equipe e equipamento, o que também influencia o valor. O diagnóstico inicial, feito sobre os discos ou imagens, é o que permite estimar com precisão o trabalho necessário; sem ele, qualquer número é chute.
O que define se um caso é viável — e, portanto, se há serviço a ser contratado — é o estado físico dos discos e a integridade dos metadados de RAID e sistema de arquivos. Setores ilegíveis em áreas de dados podem ser contornados por paridade em RAID 5 ou 6; setores ilegíveis em áreas de metadados críticos podem inviabilizar a reconstrução. Por isso, a orientação técnica é sempre a mesma: interromper novas tentativas, preservar o estado atual dos discos e buscar diagnóstico especializado antes de qualquer ação adicional. O artigo sobre RAID que parou de funcionar detalha o que fazer — e o que não fazer — nas primeiras horas após a falha.
