Dual-Boot-Maschine mit Ubuntu 20.04 und Windows 10 auf separaten M.2 NVMe-Speichergeräten. Ich habe eine externe Festplatte (14 TB), die als NTFS eingerichtet ist. Auf beiden Betriebssystemen kann ich auf die Disc schreiben. Wenn ich jedoch Dateien auf der Festplatte in Windows 10 öffne, die ich mit Ubuntu 20.04 erstellt habe, sind sie oft beschädigt. Beispiel:
D:\my\path> type myfile.mrc.tlt
The file or directory is corrupted and unreadable.
Ich habe dieses Verhalten bei zwei externen Festplatten (einer von Seagate und einer von WD) beobachtet. Ich war davon ausgegangen, dass das Problem bei der Seagate-Festplatte lag. Aber jetzt habe ich es bei einer von WD reproduziert.
Ich weiß nicht genau, wo ich hier mit der Fehlerbehebung beginnen soll.
Wenn ich das Laufwerk im laufenden Betrieb mounte journalctl -ferhalte ich folgende Meldung:
Nov 05 17:12:21 axoneme udisksd[894]: Mounted /dev/sdd1 at /media/jared/Elements on behalf of uid 1000
Nov 05 17:12:21 axoneme dbus-daemon[1641]: [session uid=1000 pid=1641] Activating via systemd: service name='org.freedesktop.Tracker1' unit='tracker-store.service' requested by ':1.1' (uid=1000 pid=1637 comm="/usr/libexec/tracker-miner-fs " label="unconfined")
Nov 05 17:12:21 axoneme systemd[1629]: Starting Tracker metadata database store and lookup manager...
Nov 05 17:12:21 axoneme dbus-daemon[1641]: [session uid=1000 pid=1641] Activating service name='org.gnome.Shell.HotplugSniffer' requested by ':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] Successfully activated service 'org.gnome.Shell.HotplugSniffer'
Nov 05 17:12:21 axoneme dbus-daemon[1088]: [session uid=125 pid=1088] Successfully activated service 'org.freedesktop.Tracker1'
Nov 05 17:12:21 axoneme systemd[1072]: Started Tracker metadata database store and lookup manager.
Nov 05 17:12:21 axoneme dbus-daemon[1641]: [session uid=1000 pid=1641] Successfully activated service 'org.freedesktop.Tracker1'
Nov 05 17:12:21 axoneme systemd[1629]: Started Tracker metadata database store and lookup manager.
Nov 05 17:12:21 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10255 > 9984): Illegal seek
Nov 05 17:12:21 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10256 > 9984): Illegal seek
Nov 05 17:12:21 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10164 > 9984): Illegal seek
Nov 05 17:12:21 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10165 > 9984): Illegal seek
Nov 05 17:12:22 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10009 > 9984): Illegal seek
Nov 05 17:12:22 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10010 > 9984): Illegal seek
Nov 05 17:12:22 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10030 > 9984): Illegal seek
Nov 05 17:12:22 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10031 > 9984): Illegal seek
Wenn ich Ubuntu 20.04 in einem Verzeichnis auf der NTFS-Festplatte ausführe ls -lth, erhalte ich in den beschädigten Verzeichnissen Folgendes:
Nov 05 17:16:03 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10294 > 9984): Illegal seek
Nov 05 17:16:03 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10290 > 9984): Illegal seek
Nov 05 17:16:03 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10360 > 9984): Illegal seek
Antwort1
Aus den Kommentaren ging hervor, dass das Problem auftritt, sobald Windows auf die NTFS-Partition zugreift. Handelt es sich also um ein Windows-Problem? Es sieht wahrscheinlich aus, obwohl es möglich ist, dass der ntfs-3g FUSE-Treiber etwas im Vergleich zum Windows-Treiber falsch interpretiert, was zu einer Inkompatibilität führt.
Es ist interessant, dass dieses Problem äußerst selten zu sein scheint(Ich habe nur ein paar Posts mit den genauen Fehlern von journalctl gefunden, einen aus dem Jahr 2008 und einen anderen über eine merkwürdige Interaktion mit RAID). Das sollte man beachten, denn es könnte bedeuten, dass Sie eine spezielle Konfiguration haben, die diese Probleme verursacht, und es wäre sehr interessant herauszufinden, was das sein könnte. Aber das überlasse ich als Übung dem Leser.
Als Workaround können Sie Folgendes versuchen:
Probieren Sie das neue NTFS3Kernel-Treiber(im Gegensatz zu NTFS-3G, das Sie verwenden),von Paragon Software seit Linux 5.15 zum Kernel beigetragen. Nicht zu verwechseln mit älteren schreibgeschützten NTFS-Kerneltreibern, die noch immer nicht entfernt wurden. Sie müssen auf 5.15 oder eine höhere Linux-Kernelversion aktualisieren. Die 5.15 scheint in 22.04 standardmäßig verwendet zu werden.(und ich empfehle Ihnen, von 20.04 auf 22.04 zu aktualisieren, da Ihnen mit einer älteren Software auf Ihrem 20.04 viele Optimierungen und Funktionen entgehen).
Ich weiß nicht spontan, wie ich Dateimanager dazu bringe, standardmäßig NTFS3 zu verwenden, aber Sie könnten beispielsweise einen
/etc/fstabEintrag hinzufügen, der den NTFS3-Treiber verwendet.Dies kann bei Ihrem Problem helfen oder auch nicht. Wenn dies jedoch nicht der Fall ist, bin ich zu 97 % sicher, dass dies ein reiner Fehler Ihres Windows-Systems ist.(siehe auch meinen Punkt zur Seltenheit). Der Grund für mein Vertrauen liegt darin, dass Paragon Software ein altes Unternehmen ist, das seine Dateisystemtreiber schon seit langer Zeit verkauft, und ich bin ziemlich sicher, dass sie über genügend Fachwissen und praktische Erfahrung verfügten, um mögliche Inkompatibilitäten mit dem ursprünglichen Windows-Treiber zu beheben.
Wenn Sie NTFS speziell zum Freigeben von Dateien verwenden, sollten Sie auch Folgendes in Betracht ziehen:
- Stattdessen wird das UDF-Dateisystem verwendet. Es wird sowohl von Windows als auch von Linux unterstützt.
- Verwendung von exfat.Seit 5.7 hat SAMSUNG einen Treiber für exfat hinzugefügt, und sieebenfalls erschienen
exfatprogs, damit die richtige Unterstützung vorhanden ist.
PS: Idealerweise sollten Sie auch das neueste NTFS-3G ausprobieren. Wenn das Problem dann immer noch reproduzierbar ist, melden Sie den Fehler. Allerdings müssen Sie die Entwickler möglicherweise davon überzeugen, dass es sich wirklich um ein NTFS-3G-Problem handelt. Wenn der NTFS3-Treiber bei Ihnen einwandfrei funktioniert, könnte dies ein impliziter Beweis dafür sein, dass das Problem beim NTFS-3G-Treiber liegt.