Problema estranho ao montar HD externo

[peterson.235]

Olá pessoal, estou com um problema que é parecido com este outro já perguntado no fórum mas não é o mesmo; a mensagem de erro é a mesma mas creio que as situações são diferentes.

Eu tenho um HD Externo de 2TB com uma partição NTFS. Se eu conecto o HD no meu desktop principal, ele monta tranquilo no Dolphin - eu só clico no HD quando ele aparece na barra lateral, e posso ver todos os arquivos, navegar, mexer com eles, etc. Esse computador tá rodando Kubuntu 22.04, e pode ser útil saber que esse foi o primeiro PC que eu usei pra mexer nesse HD.

Quando eu conecto o HD num laptop, que tá rodando um Kubuntu 23.10 que acabei de instalar nele, o HD aparece na barra lateral do Dolphin, mas quando clico pra montar ele dá uma mensagem de erro:

Error mounting /dev/sdb1: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/sdb1 at /media/root/TOSHIBA EXT: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error

Fiquei apavorado que já deu problema de disco/partição, mas esse é um HD externo novinho em folha! Levei ele de volta pro desktop e está tudo certo com ele.

Aí voltei o HD pro laptop e tentei montá-lo com udiskctl, e não só não funcionou como me deu a mesma mensagem de erro - então imagino que o Dolphin esteja usando o udisks, o que significa que o problema não está no KDE mas sim no udisks ou com algumas permissões/configurações.

Finalmente usei um simples comando mount. O terminal me disse que eu tinha que ser root, então eu rodei um

sudo mount /dev/sdb1 /media/mountpoint

e funcionou perfeitamente! Eu inclusive consegui mexer com os arquivos dentro do HD sem qualquer reclamação quanto a permissões.

Eu testei o HD externo em outro laptop, que também tá rodando o Kubuntu 23.10 (só que esse é um sistema mais antigo, que fiz upgrade). Deu os mesmos erros, e as mesmas soluções se aplicaram.

Pesquisei no Google e no AskUbuntu por uma resposta, e encontrei um cenário parecido o bastante pra tentar algumas coisas. Eu tentei:

• deletar /media/“usuário” pra que o sistema recriasse essa pasta de novo ao tentar montar o HD;
• fazer chown em /media/“usuário” tanto pra usuário:usuário quanto, depois, pra usuário:root; e
• fazer chown em /media tanto pra usuário:usuário quanto pra usuário:root.

Nada funcionou; eu retornei o /media pra propriedade do root, deletei a pasta do usuário dentro de /media (que o sistema depois recriou em mais uma tentativa fracassada de montar o HD via GUI; foi a mesma mensagem de erro, é sempre a mesma mensagem de erro).

Percebam que quando eu montei o HD com “sudo mount” o Dolphin mudou a entrada dele na barra lateral pro jeito como ela fica com o HD montado, tipo, dando pra ver o espaço livre dentro, etc - isso inclusive me permitiu desmontar o HD ali no Dolphin, porém ele me pediu a senha. Ainda que isso não seria bem uma solução, é engraçado né, não entendo por que então ele não poderia me pedir a senha pra montar a desgraça…

Eu tô ligado que eu poderia adicionar o UUID da partição no fstab em ambos os laptops, mas isso não resolveria o problema - afinal, isso não é pra acontecer! Além disso, o primeiro laptop (no qual eu descobri o problema) eu tô arrumando pra ser usado pela minha companheira, que é leiga e simplesmente não vai abrir um terminal quando ela precisar, por exemplo, mexer no HD externo de alguém e o sistema não conseguir abrir.

Adiciono ainda que pen drives fat32 não dão nenhum problema pra montar via GUI.

Desde já agradeço por ideias de como resolver isso!!

[sparrow]

intala o ntfs-3g e tenta montalo novamente
sudo apt install ntfs-3g

[kalebepsouza]

Isso não é mais necessário hoje em dia!

[kalebepsouza]

Tente usar o Gnome Disks e verificar a integridade do sistema de arquivos ntfs no seu HD.

[peterson.235]

Olá sparrow,

O ntfs-3g já vem instalado com o Kubuntu.

Inclusive só pra confirmar tentei instalar e ele me disse que já estava instalado

[peterson.235]

Olá kalebepsouza,

Mas faz sentido qualquer problema de saúde do drive ou da partição estar incomodando os sistemas? Não só ele é novo como eu consigo usá-lo normalmente, sem qualquer problema de montagem, no meu sistema 22.04.

Aliás eu consigo usá-lo sem qualquer problema nesses próprios sistemas. O único problema está nesse procedimento manual que preciso fazer para montá-lo, mas usando sudo mount ele monta tranquilamente.

[kalebepsouza]

Mano o Kernel Linux já lê ntfs nativamente via driver embutido no kernel.

[aguamole]

Ele lé, mas não escreve, a escrita é feita pelos módulos do ntfs-3g.
Não é gnomedisk, é a escrita que é feita com o ntfs-3g, se o gnomedisk usa eu não sei.

[kalebepsouza]

Lê e escreve. Desculpa a pergutna, mas vi algumas postagens suas. Vc entrou no mundo linux a pouco tempo num foi?

[aguamole]

Foi nada(10 caractere)

[sparrow]

umm tenta remontalo em outro lugar
com

sudo umount /dev/sdb* || :
sudo mkdir /mnt/meu_hdd
sudo mount -o remount,rw /dev/sdb1 /mnt/meu_hdd

[peterson.235]

Oi sparrow,

Ele vai montar. Não há dúvida. Não estou procurando por um comando para montá-lo, isso eu já consigo fazer. Estou questionando por que eu não consigo fazer isso via GUI no Dolphin, que é o que preciso habilitar pra um usuário leigo.

[sparrow]

Há entendi agora, talvez um kernel mais novo resolva parece q é esse bug mesmo.

https://www.mail-archive.com/kde-bugs-dist@kde.org/msg624454.html

[sparrow]

esse kra tb teve o mesmo erro mesma versao do 23.10 porem gnome

23.10 Cannot mount USB key

[Karan_Luciano]

O problema que você descreveu parece estar relacionado com a forma como o Kubuntu 23.10 está lidando com a montagem automática de dispositivos NTFS. Considerando que o HD funciona perfeitamente em outros sistemas e a montagem manual via sudo mount funciona sem problemas, o problema não parece ser com o disco, mas sim com alguma configuração ou permissão no sistema que está impedindo a montagem automática.

Algumas possíveis soluções para investigar são:

1. Verificar as Dependências do NTFS-3G: Certifique-se de que o pacote ntfs-3g está instalado corretamente. Este pacote é essencial para a montagem de dispositivos NTFS em sistemas Linux.
2. Permissões do udisks: Como você mencionou que o problema pode estar relacionado ao udisks, pode ser útil verificar as permissões e configurações relacionadas a ele. Certifique-se de que seu usuário tenha as permissões necessárias para usar o udisks sem precisar de privilégios de superusuário.
3. Verificar o Polkit: O Polkit (anteriormente conhecido como PolicyKit) é um componente do sistema que controla privilégios do sistema. Pode haver alguma política impedindo a montagem automática de dispositivos NTFS para usuários regulares.
4. Logs do Sistema: Verifique os logs do sistema para obter mais informações sobre o erro. O comando dmesg ou o visualizador de logs do sistema podem fornecer pistas importantes.
5. Atualizações e Repositórios: Certifique-se de que o sistema está atualizado e que todos os repositórios estão corretamente configurados. Algumas vezes, problemas desse tipo são resolvidos com atualizações de sistema ou pacotes.
6. Testar com Outro Usuário: Crie um novo usuário no sistema e teste a montagem do HD para verificar se o problema é específico do usuário atual.

Como você mencionou que a solução via fstab não é ideal para o seu caso, o foco deve ser em resolver o problema de montagem automática para usuários regulares.

[peterson.235]

sparrow, seu primeiro comentário sobre o bug no kernel me levou a mais pesquisas que finalmente me levaram a uma solução!! Vou descrevê-la aqui caso alguém passe por algo semelhante.

No link que você passou, sugere-se mudar as políticas do udisks pra ele montar o drive de uma forma específica, colocando

[defaults]
ntfs_defaults=uid=$UID,gid=$GID

no arquivo /etc/udisks2/mount_options.conf

Isso não funcionou. Olhando no arquivo de exemplo pra essa configuração (mount_options.conf.example na mesma pasta), eu vi que podia ser porque faltou um “ntfs:” no início da linha de config. Outra mensagem em outro fórum sugeriu colocar uma barra antes de cada cifrão nessa linha. Eu fiz essas mudanças, uma por uma e com reboots entre elas, pra ir testando o efeito de cada configuração. Não mudou nada.

Depois que eu vi que essa mensagem era de 2021, eu pensei - mas pera aí… Meu sistema 22.04 está montando o HD tranquilamente. Ele também é afetado por esse bug, mas funciona. Como? Então encontrei uma reclamação na internet de que em algum momento por aí - 2021, 2022 - o Ubuntu ainda estava usando o ntfs-3g a despeito da disponibilidade do ntfs3 no kernel. Aí eu comecei a procurar por formas de forçar o udisks dos Kubuntu 23.10 que tenho nos laptops a usar o ntfs-3g, como eu presumi (embora não tenha chegado a descobrir se é isso mesmo) que o meu desktop 22.04 estava usando. Descobri que bastava desinstalar o módulo ntfs3 no kernel pro udisks naturalmente cair pra usar a alternativa, o ntfs-3g.

Mas não cheguei a fazer nada disso, porque na pesquisa pra forçar o uso do ntfs-3g achei outra coisa.

Achei alguém no github do udisks reclamando que o ntfs3, ao contrário do ntfs-3g, se recusava a montar qualquer partição que estivesse “marcada” (flagged) como danificada, mesmo que obviamente ela não esteja já que o 3g consegue fazer tudo com ela normalmente. A solução é simples: rodar um

ntfsfix -d

na partição afetada. E tem que ser com sudo.

Eu rodei e deu certo! Nos dois laptops com 23.10 a montagem com o Dolphin está funcionando perfeitamente.

Observo também que é basicamente isso que o Gnome Disks deve fazer na opção “repair system” mostrada no segundo link que você passou, sparrow, com o cara que teve esse problema no gnome. No final das contas, inclusive, é o que o kalebepesouza também sugeriu, eu só não sabia que checar a saúde do drive poderia ser útil mesmo que não houvesse problema nenhum na prática (p. ex. em outro sistema linux)

Eu concluo pensando o seguinte:

1. Eu só tive confiança de usar o ntfsfix porque eu estava bem certo de que a partição estava funcional. Afinal de contas, se realmente houvesse um problema, a solução poderia envolver perda de dados.
2. Sendo assim, isso até é uma “solução” para o meu caso específico, mas se p. ex. minha companheira enfrentar o mesmo problema com o HD externo de uma terceira pessoa, eu não vou sugerir pra ela fazer isso pra resolver. Vou dizer que a pessoa deve checar o estado de saúde do drive dela…
3. Por outro lado, ainda é um problema que o Ubuntu não consiga pegar essa flag de dano e “duvidar” dela, p. ex. tentando montar o sistema em ntfs-3g pra ver se há motivo mesmo pra preocupação ou se dá pra tirar a flag (que foi o que eu entendi que o ntfsfix fez) e montar do mesmo jeito. Mas aí acho que essa discussão já está rolando ali no link onde achei a solução.

Obrigado a todos que comentaram pra tentar achar uma solução!!

[kalebepsouza]

Tipo assim. Se o sistema de arquivos do HD externo estiver com algum problema, alguns sistemas não irão montar.