1 votes

Jacob Anderson avatar

Problèmes avec le disque dur partagé NTFS | Ubuntu 20.04 x Windows 10

Demandé el 5 de Novembre, 2022
Quand la question a-t-elle été
82 affichage
Nombre de visites la question a
1 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Machine dual boot avec Ubuntu 20.04 et Windows 10 sur des dispositifs de stockage m.2 nvme séparés. J'ai un disque dur externe (14 To) configuré en NTFS. Sur l'un ou l'autre système d'exploitation, je peux écrire sur le disque. Cependant, lorsque j'ouvre des fichiers sur le disque dur dans Windows 10, s'ils ont été générés en utilisant Ubuntu 20.04, ils sont souvent corrompus. Par exemple :

D:\mon\chemin> type monfichier.mrc.tlt
Le fichier ou le répertoire est corrompu et illisible.

J'ai constaté ce comportement sur deux disques durs externes (un Seagate et un autre WD). J'avais supposé que le problème venait du disque Seagate. Mais je l'ai maintenant reproduit avec un WD.

Je ne sais pas par où commencer le dépannage à partir d'ici.

Lorsque je monte le disque tout en exécutant journalctl -f j'obtiens ce qui suit :

Nov 05 17:12:21 axoneme udisksd[894]: Monté /dev/sdd1 sur /media/jared/Elements pour le compte de l'uid 1000
Nov 05 17:12:21 axoneme dbus-daemon[1641]: [session uid=1000 pid=1641] Activation via systemd : service name='org.freedesktop.Tracker1' unit='tracker-store.service' demandé par ':1.1' (uid=1000 pid=1637 comm="/usr/libexec/tracker-miner-fs " label="unconfined")
Nov 05 17:12:21 axoneme systemd[1629]: Démarrage de Tracker metadata database store and lookup manager...
Nov 05 17:12:21 axoneme dbus-daemon[1641]: [session uid=1000 pid=1641] Activation du service name='org.gnome.Shell.HotplugSniffer' demandé par ':1.37' (uid=1000 pid=1860 comm="/usr/bin/gnome-shell " label="unconfined")
Nov 05 17:12:21 axoneme dbus-daemon[1641]: [session uid=1000 pid=1641] Activation réussie du service 'org.gnome.Shell.HotplugSniffer'
Nov 05 17:12:21 axoneme dbus-daemon[1088]: [session uid=125 pid=1088] Activation réussie du service 'org.freedesktop.Tracker1'
Nov 05 17:12:21 axoneme systemd[1072]: Tracker metadata database store and lookup manager démarré.
Nov 05 17:12:21 axoneme dbus-daemon[1641]: [session uid=1000 pid=1641] Activation réussie du service 'org.freedesktop.Tracker1'
Nov 05 17:12:21 axoneme systemd[1629]: Tracker metadata database store and lookup manager démarré.
Nov 05 17:12:21 axoneme ntfs-3g[5491]: Tentative de lecture de mft records non alloués (10255 > 9984) : déplacement illégal
Nov 05 17:12:21 axoneme ntfs-3g[5491]: Tentative de lecture de mft records non alloués (10256 > 9984) : déplacement illégal
Nov 05 17:12:21 axoneme ntfs-3g[5491]: Tentative de lecture de mft records non alloués (10164 > 9984) : déplacement illégal
Nov 05 17:12:21 axoneme ntfs-3g[5491]: Tentative de lecture de mft records non alloués (10165 > 9984) : déplacement illégal
Nov 05 17:12:22 axoneme ntfs-3g[5491]: Tentative de lecture de mft records non alloués (10009 > 9984) : déplacement illégal
Nov 05 17:12:22 axoneme ntfs-3g[5491]: Tentative de lecture de mft records non alloués (10010 > 9984) : déplacement illégal
Nov 05 17:12:22 axoneme ntfs-3g[5491]: Tentative de lecture de mft records non alloués (10030 > 9984) : déplacement illégal
Nov 05 17:12:22 axoneme ntfs-3g[5491]: Tentative de lecture de mft records non alloués (10031 > 9984) : déplacement illégal

De même, si j'exécute ls -lth dans un répertoire sur le disque HD avec Ubuntu 20.04, j'obtiens ce qui suit dans les répertoires corrompus :

Nov 05 17:16:03 axoneme ntfs-3g[5491]: Tentative de lecture de mft records non alloués (10294 > 9984) : déplacement illégal
Nov 05 17:16:03 axoneme ntfs-3g[5491]: Tentative de lecture de mft records non alloués (10290 > 9984) : déplacement illégal
Nov 05 17:16:03 axoneme ntfs-3g[5491]: Tentative de lecture de mft records non alloués (10360 > 9984) : déplacement illégal
Demandé el 5 de Novembre, 2022 par Jacob Anderson

Réponse

Trop de publicités?

1voto

Hi-Angel avatar
Hi-Angel Points 3233

Donc, la discussion dans les commentaires a montré que le problème commence à se produire une fois que Windows accède à la partition NTFS. Donc, est-ce un problème de Windows ? Il semble probable, bien qu'il y ait une chance que le pilote FUSE ntfs-3g interprète quelque chose de manière incorrecte par rapport à celui de Windows, ce qui entraîne une incompatibilité.

Il est intéressant de noter que ce problème semble être extrêmement rare (j'ai trouvé juste quelques publications avec les erreurs exactes de journalctl, une de l'année 2008, et une autre concernant une interaction étrange avec un RAID). C'est quelque chose à noter, car cela pourrait impliquer que vous avez une configuration spéciale qui cause ces problèmes, et ce serait très intéressant de découvrir ce que cela pourrait être. Mais je laisserai cela comme un exercice pour le lecteur.

En termes de solution de contournement, vous pouvez essayer :

  1. Essayez le nouveau pilote de noyau ntfs3 (par opposition à ntfs-3g que vous utilisez), contribué dans le noyau par Paragon Software depuis Linux 5.15. A ne pas confondre avec l'ancien pilote de noyau ntfs en lecture seule, qui n'a pas encore été supprimé. Vous devrez mettre à jour vers la version du noyau Linux 5.15 ou supérieure. La version 5.15 semble être utilisée par défaut dans la 22.04 (et je vous recommande de mettre à jour de 20.04 à 22.04 car en utilisant un logiciel plus ancien sur votre 20.04, vous manquez de nombreuses optimisations et fonctionnalités).

    En passant, je ne sais pas comment faire en sorte que les gestionnaires de fichiers utilisent ntfs3 par défaut, mais vous pourriez par exemple ajouter une entrée /etc/fstab qui utilise le pilote ntfs3.

    Cela peut ou non aider avec votre problème. Mais si ce n'est pas le cas, alors je suis à 97% sûr que c'est purement un problème spécifiquement de votre système Windows (voir aussi mon point sur la rareté). La raison de ma confiance est que Paragon Software est une vieille entreprise qui vendait ses pilotes de système de fichiers depuis longtemps, et je suis assez sûr qu'ils avaient suffisamment d'expertise et d'expérience pratique pour résoudre les incompatibilités possibles avec le pilote Windows original.

  2. Si vous utilisez spécifiquement NTFS pour partager des fichiers, vous pourriez également envisager :

    1. Utiliser le système de fichiers UDF à la place. Il est pris en charge à la fois par Windows et Linux.
    2. Utiliser exfat. Depuis 5.7, SAMSUNG a ajouté un pilote pour exfat, et ils ont également publié exfatprogs, donc le support adéquat est en place.

P.S. : idéalement, vous devriez également essayer la dernière version de ntfs-3g, puis si le problème est toujours reproductible, signaler un bug. Bien que vous deviez peut-être convaincre les développeurs que c'est vraiment un problème de ntfs-3g. Si le pilote ntfs3 fonctionne bien pour vous, alors cela pourrait être une preuve implicite que le problème se situe dans le pilote ntfs-3g.

Répondu el 6 de Novembre, 2022 par Hi-Angel (3233 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X