Entre Mapas e Máquinas

Recentemente me deparei com um problema bastante curioso em uma máquina configurada em dual boot com Windows 11 e Pop!_OS.

Um SSD SATA de 512 GB, formatado em NTFS, funcionava perfeitamente no Windows. Todos os arquivos estavam acessíveis, o sistema não relatava erros e a unidade era utilizada normalmente. Entretanto, ao iniciar o Pop!_OS, o disco simplesmente se recusava a montar.

As mensagens de erro eram genéricas e sugeriam problemas no sistema de arquivos. Como acontece com frequência em fóruns e grupos de suporte, muitas soluções encontradas na internet apontavam para formatação da unidade ou suspeita de defeito físico no SSD.

Antes de tomar qualquer decisão drástica, resolvi investigar o problema de forma sistemática. O resultado revelou uma situação interessante envolvendo diferenças entre os drivers NTFS disponíveis no Linux.

Sintomas observados

Os sintomas eram os seguintes:

• O SSD aparecia normalmente no sistema.
• O comando lsblk -f identificava a partição NTFS corretamente.
• O Windows acessava todos os arquivos sem qualquer problema.
• O Pop!_OS não conseguia montar a unidade.
• O utilitário ntfsfix não encontrava erros graves.
• O SSD apresentava estado de saúde normal segundo o SMART.

A mensagem exibida pelo sistema era semelhante a:

wrong fs type, bad option, bad superblock on /dev/sdc1

À primeira vista, tudo indicava corrupção da partição. Porém, os testes começaram a mostrar um cenário diferente.

Verificando o sistema de arquivos

O primeiro passo foi identificar o volume:

lsblk -f

O resultado mostrava a partição normalmente:

sdc1 ntfs SSD 2

Ou seja, o hardware era reconhecido pelo sistema e o Linux conseguia identificar o tipo de sistema de arquivos.

Em seguida executei:

sudo ntfsfix -n /dev/sdc1

O utilitário informou que:

• A MFT estava íntegra.
• A MFT Mirror estava íntegra.
• O setor de boot estava íntegro.

Nenhuma evidência de corrupção crítica foi encontrada.

Investigando os logs do kernel

O passo seguinte foi consultar os logs do sistema:

sudo dmesg | tail -50

Foi nesse momento que apareceram mensagens mais reveladoras:

ntfs3(sdc1): Failed to load $BadClus (-22)
ntfs3(sdc1): Mark volume as dirty due to NTFS errors
ntfs3(sdc1): volume is dirty and "force" flag is not set!

Essas mensagens apontavam para uma dificuldade do driver ntfs3 ao interpretar informações relacionadas à estrutura interna $BadClus do volume NTFS.

O SSD estava saudável?

Antes de prosseguir, resolvi descartar qualquer hipótese de falha física.

Utilizei:

sudo smartctl -a /dev/sdc

Os principais indicadores mostravam:

SMART overall-health self-assessment test result: PASSED
Reallocated_Sector_Ct = 0
Current_Pending_Sector = 0
Offline_Uncorrectable = 0
UDMA_CRC_Error_Count = 0

Em outras palavras:

• Nenhum setor remapeado.
• Nenhum setor pendente.
• Nenhum erro de comunicação.
• SSD considerado saudável.

Isso reforçou a hipótese de que o problema não estava no hardware.

O CHKDSK também não resolveu

A partir do Windows executei:

chkdsk X: /f

O procedimento foi concluído sem erros relevantes.

Contudo, ao retornar ao Linux, a situação permanecia exatamente a mesma.

A descoberta

A investigação então seguiu por outro caminho: testar um driver NTFS diferente.

O Pop!_OS estava tentando montar a unidade utilizando o driver moderno ntfs3, integrado ao kernel Linux.

Resolvi testar o tradicional ntfs-3g.

Durante os testes descobri que havia um processo de montagem preso:

sudo fuser -v /dev/sdc1

Resultado:

root 4680 mount.ntfs-3g

Após encerrar o processo:

sudo kill 4680

executei:

sudo ntfs-3g /dev/sdc1 /mnt/ssd2

Desta vez a montagem ocorreu imediatamente.

Todos os arquivos ficaram acessíveis:

CHRONOS Releases
Games
GOG Games
Retrobat
torrents

Solução permanente

Para evitar que o sistema utilizasse novamente o driver ntfs3, configurei uma entrada específica no arquivo /etc/fstab:

UUID=01D8D813CA527750 /mnt/ssd2 ntfs-3g defaults,uid=1000,gid=1000,nofail 0 0

Após reiniciar o sistema, a unidade passou a ser montada automaticamente utilizando ntfs-3g. IMPORTANTE: Lembre-se que essa UUID é a do meu SSD, você precisa descobrir a do seu com o seguinte comando: sudo blkid /dev/sdc1

Conclusão

O SSD não possuía defeitos físicos.

O sistema de arquivos também não apresentava corrupção significativa.

O problema estava relacionado à forma como o driver ntfs3 lidava com determinadas estruturas internas do volume NTFS. Enquanto o ntfs3 recusava a montagem, o ntfs-3g conseguia acessar a mesma partição sem dificuldades.

Lições aprendidas

• Nem todo erro de montagem NTFS significa defeito físico no SSD.
• Verificar o SMART pode evitar diagnósticos equivocados.
• O comando dmesg é uma ferramenta fundamental para entender falhas de montagem.
• Os drivers ntfs3 e ntfs-3g possuem comportamentos diferentes diante de determinadas inconsistências.
• Antes de formatar um disco, vale a pena testar alternativas de montagem.

Se você encontrou este artigo porque está enfrentando um problema semelhante, experimente testar o ntfs-3g antes de assumir que a unidade está perdida.

11 de Junho de 2026 – Alan A. Alievi