In meinem Fall war die Partition noch in einem unsauberen NTFS-Zustand. Nach einer Reparatur mit ntfsfix und einem expliziten Mount mit ntfs-3g ließ sie sich wieder normal beschreiben.

Das Problem

Die NTFS-Partition war vorhanden und lesbar, Schreibzugriffe funktionierten aber nicht.

Zunächst sollte man herausfinden, unter welchem Gerätenamen Linux die betreffende Partition kennt:

lsblk -f

Eine typische Ausgabe sieht beispielsweise so aus:

NAME   FSTYPE LABEL
sda
└─sda1 ntfs   Fotos
sdb
└─sdb1 ntfs   Dokumente

Wichtig ist der Unterschied zwischen Gerät und Mountpoint:

/dev/sda1

ist die eigentliche Partition.

Ein Pfad wie

/media/benutzer/Fotos

oder

/mnt/fotos

ist dagegen nur das Verzeichnis, in das diese Partition eingehängt wurde.

Programme wie ntfsfix benötigen das Gerät, also beispielsweise:

sudo ntfsfix /dev/sda1

und nicht den Mountpoint.

Ursache: NTFS war als „unclean“ markiert

Nach dem Aushängen der Partition wurde sie mit ntfsfix überprüft:

sudo umount /dev/sda1
sudo ntfsfix -d /dev/sda1

Dabei meldete ntfsfix unter anderem:

The disk contains an unclean file system
Metadata kept in Windows cache, refused to mount.

Anschließend wurden unter anderem die Master File Table und deren Spiegel geprüft sowie das NTFS-Journal geleert.

Der Vorgang endete mit:

NTFS partition /dev/sda1 was processed successfully.

Damit war zumindest belegt, dass die Partition zuvor tatsächlich einen unsauberen NTFS-Zustand hatte und ntfsfix diesen bearbeitet hatte.

ntfsfix ist dabei keine vollständige NTFS-Reparatur wie ein Windows-chkdsk. Für grundlegende Inkonsistenzen und das Zurücksetzen des NTFS-Journals kann es aber ausreichen.

Einen festen Mountpoint anlegen

Beim anschließenden manuellen Mounten trat zunächst ein weiterer Fehler auf:

failed to access mountpoint ...: Datei oder Verzeichnis nicht gefunden

Der Grund war simpel: Das Zielverzeichnis existierte nach dem Aushängen nicht mehr.

Deshalb zuerst einen festen Mountpoint anlegen:

sudo mkdir -p /mnt/ntfs-daten

Danach kann die Partition mit ntfs-3g explizit als beschreibbar eingehängt werden:

sudo mount -t ntfs-3g \
  -o rw,uid=1000,gid=1000,umask=022 \
  /dev/sda1 /mnt/ntfs-daten

Die Werte 1000 waren in diesem Fall Benutzer- und Gruppen-ID des normalen Linux-Benutzers. Die eigenen Werte lassen sich prüfen mit:

id -u
id -g

Prüfen, ob die Partition wirklich schreibbar ist

Der aktuelle Mount-Status lässt sich zum Beispiel so kontrollieren:

mount | grep sda1

Im erfolgreichen Fall erschien:

/dev/sda1 on /mnt/ntfs-daten type fuseblk (rw,...)

Entscheidend ist hier:

rw

Das Dateisystem ist also read/write eingehängt.

Ein einfacher Schreibtest ist:

touch /mnt/ntfs-daten/testdatei.txt

Wenn dabei keine Fehlermeldung erscheint, funktioniert der Schreibzugriff.

Die Testdatei kann anschließend wieder entfernt werden:

rm /mnt/ntfs-daten/testdatei.txt

Damit war der Schreibzugriff in diesem Fall praktisch bestätigt.

NTFS dauerhaft über /etc/fstab einbinden

Damit die Platte nicht nach jedem Neustart manuell gemountet werden muss, kann sie in /etc/fstab eingetragen werden.

Zunächst einen dauerhaften Mountpoint anlegen:

sudo mkdir -p /mnt/ntfs-daten

Vor Änderungen an fstab empfiehlt sich eine Sicherung:

sudo cp /etc/fstab /etc/fstab.bak

Danach:

sudo nano /etc/fstab

Für die Partition kann beispielsweise folgende Zeile verwendet werden:

UUID=DEINE-UUID  /mnt/ntfs-daten  ntfs-3g  rw,uid=1000,gid=1000,umask=022,nofail,x-gvfs-show  0  0

Die UUID findet man mit:

lsblk -f

oder:

sudo blkid

Die wichtigsten Optionen:

rw

bindet die Partition beschreibbar ein.

uid=1000,gid=1000

ordnet die Dateien dem angegebenen Benutzer und seiner Gruppe zu.

umask=022

setzt passende Standardrechte.

nofail

verhindert, dass ein Problem mit diesem Datenträger den normalen Systemstart blockiert.

x-gvfs-show

kann dafür sorgen, dass die Partition auch im grafischen Dateimanager angezeigt wird.

Änderungen an fstab testen

Nach dem Speichern kann die Konfiguration getestet werden:

sudo mount -a

Wurde /etc/fstab während des laufenden Systems geändert, kann systemd darauf hinweisen, dass noch die alte Konfiguration verwendet wird:

Ihre Fstab-Datei wurde geändert, aber Systemd nutzt
noch die alte Version

Dann kann die systemd-Konfiguration neu geladen werden:

sudo systemctl daemon-reload

Fallstrick: „NTFS volume is already exclusively opened“

Beim Einrichten mehrerer NTFS-Platten trat außerdem folgende Meldung auf:

Mount is denied because the NTFS volume is already exclusively opened.
The volume may be already mounted, or another software may use it

In diesem Fall waren die betreffenden Partitionen bereits an anderen Mountpoints eingehängt.

Das lässt sich überprüfen mit:

mount | grep ntfs

oder gezielter:

findmnt

Ein NTFS-Volume sollte nicht gleichzeitig noch an einem alten Automount-Pfad hängen und zusätzlich über einen neuen fstab-Mountpoint eingebunden werden.

Vor einem erneuten Mount-Versuch muss deshalb gegebenenfalls zunächst der bereits vorhandene Mount ausgehängt werden.

Beispiel:

sudo umount /alter/mountpoint

Danach:

sudo mount -a

Neustart nach größeren fstab-Änderungen

Nach mehreren Änderungen an Mountpoints und /etc/fstab ist ein Neustart eine einfache Möglichkeit, mit einem definierten Zustand zu beginnen.

Beim Booten wird die fstab erneut verarbeitet.

sudo reboot

Hinweis: Im hier dokumentierten Ablauf wurde der Neustart als nächster Schritt vorgesehen, sein Ergebnis wurde aber nicht mehr überprüft. Der erfolgreiche Schreibzugriff auf die erste NTFS-Partition war zu diesem Zeitpunkt bereits unabhängig davon bestätigt.

Ergebnis

Der entscheidende Ablauf war:

lsblk -f

richtige NTFS-Partition ermitteln,

sudo umount /dev/sdXN
sudo ntfsfix -d /dev/sdXN

unsauberen NTFS-Zustand bearbeiten,

sudo mkdir -p /mnt/ntfs-daten

einen festen Mountpoint anlegen und anschließend:

sudo mount -t ntfs-3g \
  -o rw,uid=1000,gid=1000,umask=022 \
  /dev/sdXN /mnt/ntfs-daten

beschreibbar mounten.

Der Test:

touch /mnt/ntfs-daten/testdatei.txt

lief anschließend ohne Fehler durch.

Damit war die zuvor nur lesbare NTFS-Festplatte unter Linux Mint wieder beschreibbar.

zeigte im konkreten Fall eine NVIDIA GeForce GTX 1650.

Entscheidend waren aber mehrere andere Hinweise aus inxi:

driver: N/A
gpu: N/A

Außerdem wurde als OpenGL-Renderer nur Software-Rendering verwendet:

renderer: llvmpipe

xrandr erkannte ebenfalls nur einen einzigen Ausgang.

Damit war bereits klar: Die Grafikkarte selbst wurde vom System gesehen, aber der NVIDIA-Treiber arbeitete nicht korrekt.

Ist Secure Boot wirklich die Ursache?

Zunächst ließ sich prüfen, ob Secure Boot überhaupt aktiv war:

mokutil --sb-state

Die Ausgabe:

SecureBoot enabled

belegt zunächst nur, dass Secure Boot eingeschaltet ist. Sie beweist noch nicht, dass Secure Boot auch den NVIDIA-Treiber blockiert.

Deshalb folgten weitere Prüfungen:

ubuntu-drivers devices

dpkg -l | grep -Ei 'nvidia|linux-modules-nvidia'

lsmod | grep -Ei 'nvidia|nouveau'

modinfo nvidia 2>/dev/null | grep -Ei 'filename|version|signer|sig_id'

journalctl -k -b | grep -Ei 'nvidia|secure boot|mok|module verification|lockdown|key'

Der entscheidende Befund

Die NVIDIA-Pakete waren installiert. Im konkreten Fall war unter anderem der offene NVIDIA-Kerneltreiber der 580er-Reihe vorhanden.

modinfo zeigte außerdem, dass das NVIDIA-Modul signiert war:

sig_id: PKCS#7
signer: localhost.localdomain Secure Boot Module Signature key

Im Kernel-Log erschienen gleichzeitig Meldungen wie:

secureboot: Secure boot enabled

und:

Kernel is locked down from EFI Secure Boot mode

Vor allem aber:

Loading of module with unavailable key is rejected

Damit war die Ursache nicht mehr nur eine Vermutung.

Der NVIDIA-Kerneltreiber war vorhanden und signiert, aber der dafür verwendete Schlüssel wurde von Secure Boot nicht als vertrauenswürdig akzeptiert. Das Modul wurde deshalb nicht geladen.

Lösung: MOK-Schlüssel eintragen statt Secure Boot abschalten

Secure Boot musste in diesem Fall nicht deaktiviert werden.

Stattdessen wurde der bereits vorbereitete Machine Owner Key, kurz MOK, zur Registrierung vorgemerkt:

sudo update-secureboot-policy --enroll-key

Darauf erschien ein textbasierter Dialog mit dem Hinweis, dass für die Verwendung von Drittanbieter-Treibern unter Secure Boot ein Machine Owner Key registriert werden müsse.

In diesem Dialog wurde ein Passwort vergeben.

Falls sich ein solcher Dialog nicht mit der Maus bedienen lässt, funktionieren typischerweise:

• Tab, um zwischen Schaltflächen zu wechseln,
• Pfeiltasten zur Navigation,
• Enter oder gegebenenfalls die Leertaste zur Bestätigung.

Danach wurde das System neu gestartet.

MOK beim Neustart bestätigen

Beim nächsten Start erschien der MOK-Manager.

Dort wurde der vorbereitete Schlüssel über den Menüpunkt

Enroll MOK

registriert und mit dem zuvor vergebenen Passwort bestätigt.

Secure Boot selbst blieb dabei aktiviert.

Anschließend startete Linux Mint wieder normal.

Ergebnis prüfen

Direkt nach dem Neustart funktionierten beide Monitore wieder.

Zusätzlich ließ sich der Zustand mit folgenden Befehlen kontrollieren:

mokutil --sb-state
lsmod | grep nvidia
nvidia-smi

Secure Boot war weiterhin aktiv:

SecureBoot enabled

Gleichzeitig waren nun die NVIDIA-Module geladen, unter anderem:

nvidia
nvidia_modeset
nvidia_drm
nvidia_uvm

Auch nvidia-smi erkannte die GeForce GTX 1650 wieder korrekt und zeigte den NVIDIA-Treiber als aktiv an.

Damit war der Fehler behoben.

Was hier tatsächlich passiert war

Der Ablauf ließ sich in diesem Fall eindeutig nachvollziehen:

1. Die NVIDIA-Grafikkarte wurde vom System erkannt.
2. Der NVIDIA-Kerneltreiber war installiert.
3. Das Kernelmodul war signiert.
4. Secure Boot war aktiviert.
5. Der verwendete Signaturschlüssel war nicht als vertrauenswürdig registriert.
6. Der Kernel verweigerte deshalb das Laden des NVIDIA-Moduls.
7. Linux fiel auf Software-Rendering zurück.
8. Dadurch stand auch die normale NVIDIA-Ausgabe für die angeschlossenen Monitore nicht zur Verfügung.
9. Nach Registrierung des MOK-Schlüssels konnte das Modul geladen werden.
10. Beide Bildschirme funktionierten wieder.

Diagnose in Kurzform

Wenn Linux Mint mit NVIDIA-Grafik plötzlich nur noch einen Monitor erkennt, kann folgende Reihenfolge sinnvoll sein:

mokutil --sb-state

xrandr
inxi -Gxx
lspci | grep -Ei 'vga|3d|display'

ubuntu-drivers devices
dpkg -l | grep -Ei 'nvidia|linux-modules-nvidia'
lsmod | grep -Ei 'nvidia|nouveau'

modinfo nvidia 2>/dev/null | grep -Ei 'filename|version|signer|sig_id'

journalctl -k -b | grep -Ei 'nvidia|secure boot|mok|module verification|lockdown|key'

Besonders aussagekräftig ist eine Kombination aus:

driver: N/A

oder Software-Rendering über:

llvmpipe

und Kernel-Meldungen wie:

Loading of module with unavailable key is rejected

Erst damit ist tatsächlich belegt, dass nicht nur ein allgemeines NVIDIA-Problem vorliegt, sondern die Vertrauenskette von Secure Boot das Laden des Moduls verhindert.

Fazit

In diesem Fall war das Abschalten von Secure Boot nicht nötig.

Die bessere Lösung bestand darin, den bereits signierten NVIDIA-Kerneltreiber über einen registrierten Machine Owner Key für Secure Boot vertrauenswürdig zu machen.

Der Vorteil: Der NVIDIA-Treiber funktioniert wieder, beide Monitore stehen zur Verfügung und Secure Boot kann aktiviert bleiben.

Für „Patches & Notes“ eignet sich das aus meiner Sicht gut als klassischer **Fehlerbild → Diagnose → belegte Ursache → Reparatur → Verifikation**-Artikel. Ich habe dabei bewusst die konkreten lokalen Hostnamen und den ausgegebenen lokalen Systempfad des MOK-Schlüssels weggelassen.

rsync error: some files/attrs were not transferred
(code 23)

Gleichzeitig waren aber bereits hunderte Gigabyte erfolgreich am Ziel angekommen.

Die wichtige Frage war deshalb nicht:

Ist rsync fehlgeschlagen?

Sondern:

Welche Dateien fehlen tatsächlich?

Ausgangslage

Eine ältere NTFS-Festplatte sollte auf einen neuen Datenträger kopiert werden.

Verwendet wurde sinngemäß:

rsync -rlt --partial --info=progress2 \
"/media/user/ALTE_PLATTE/Backup" \
"/mnt/NEUE_PLATTE/"

Der Kopiervorgang lief lange normal.

Dann tauchten Meldungen wie diese auf:

read errors mapping "...": Input/output error (5)

und schließlich:

rsync error: some files/attrs were not transferred
(code 23)

Exit-Code 23 bedeutet nicht: nichts wurde kopiert

Bei einem großen Verzeichnisbaum kann rsync tausende Dateien erfolgreich übertragen und trotzdem am Ende mit Code 23 zurückkehren.

Im konkreten Fall wurden mehrere hundert Gigabyte übertragen.

Nur einzelne Dateien konnten wegen Lesefehlern der Quellfestplatte nicht erfolgreich kopiert werden.

Deshalb wäre es falsch gewesen, den kompletten Kopiervorgang als unbrauchbar anzusehen.

Entscheidend: endgültige Fehlermeldungen

Während des Laufs gab es vereinzelt Lesefehler bei Dateien, die später trotzdem übertragen werden konnten.

Besonders relevant waren dagegen Meldungen wie:

failed verification -- update discarded

Hier hatte rsync die Zieldatei nicht als erfolgreich übertragen akzeptiert.

Diese Dateien mussten später separat behandelt werden.

Warum rsync dafür praktisch ist

Ein großer Vorteil von rsync ist, dass ein Kopiervorgang erneut gestartet werden kann.

Bereits vorhandene Dateien müssen dabei nicht zwangsläufig komplett noch einmal übertragen werden.

Das ist gerade bei einer angeschlagenen Festplatte hilfreich:

Man möchte möglichst vermeiden, bereits erfolgreich gelesene Daten immer wieder unnötig von der problematischen Platte anzufordern.

—partial bei großen Dateien

Verwendet wurde außerdem:

--partial

Dadurch können teilweise übertragene Dateien erhalten bleiben.

Das kann insbesondere bei großen Dateien sinnvoll sein.

Der verwendete Befehl sah beispielsweise so aus:

rsync -rlt --partial --info=progress2 \
"/media/user/ALTE_PLATTE/Verzeichnis" \
"/mnt/NEUE_PLATTE/Ziel/"

Nicht sofort das Dateisystem reparieren

Die auftretenden Fehler waren:

Input/output error (5)

Deshalb wurde zunächst nicht versucht, die alte NTFS-Platte zu reparieren.

Stattdessen wurde ihr SMART-Zustand untersucht:

sudo smartctl -a /dev/sdX

Dort zeigten sich zahlreiche:

Reallocated_Sector_Ct
Current_Pending_Sector
Offline_Uncorrectable

Damit war klar:

Die Ursache war nicht nur ein harmloser Kopierfehler, sondern die Platte selbst war physisch problematisch.

Erst alles Lesbare kopieren

Der weitere Ablauf war:

rsync kopiert alles noch Lesbare
        ↓
Liste der tatsächlich fehlgeschlagenen Dateien
        ↓
keine erneute Komplettkopie
        ↓
nur Problemdateien separat retten

Für die problematischen Einzeldateien wurde anschließend GNU ddrescue verwendet.

Beispiel:

ddrescue -n quelle ziel ziel.ddrescue.map
ddrescue -r3 quelle ziel ziel.ddrescue.map

Damit konnten mehrere Dateien gerettet werden, die rsync zuvor nicht mehr erfolgreich übertragen konnte.

Warum das sinnvoller war als ein Komplett-Image

Im konkreten Fall war der weit überwiegende Teil der Platte noch lesbar.

Deshalb wurde zuerst mit rsync kopiert und ddrescue anschließend nur für die wenigen Problemdateien eingesetzt.

Das vermied einen vollständigen zusätzlichen Lesedurchlauf über die bereits angeschlagene Festplatte.

Für einen anderen Schadensfall kann ein vollständiges sektorweises Abbild sinnvoll sein.

Hier war es aber nicht notwendig, weil die relevanten Daten weitgehend noch dateibasiert lesbar waren.

Praktischer Ablauf

Bei einem ähnlichen Fall würde ich anhand dieser Erfahrung so vorgehen:

1. Daten mit rsync kopieren
2. Fehlerausgabe sichern
3. nicht aufgrund von Code 23 alles verwerfen
4. endgültig fehlgeschlagene Dateien identifizieren
5. SMART prüfen
6. bei Hardwarefehlern keine unnötigen Komplettläufe mehr
7. Problemdateien gezielt mit ddrescue bearbeiten

Fazit

rsync Exit-Code 23 bedeutet:

Nicht alles konnte übertragen werden.

Er bedeutet aber nicht:

Die komplette Sicherung ist unbrauchbar.

Gerade bei einer sterbenden Festplatte kann rsync noch einen sehr großen Teil der Daten erfolgreich sichern.

Die sinnvollere Strategie war in diesem Fall:

erst alles noch Lesbare normal kopieren und anschließend nur die tatsächlich fehlgeschlagenen Dateien gezielt retten.

In meinem Fall sollte eine zuvor anderweitig verwendete SSD dauerhaft als Linux-Datenplatte eingebunden werden.

Das Ergebnis:

ext4
fester Mountpoint
Einbindung über UUID
kein Bootabbruch bei fehlender Platte
Anzeige im Dateimanager

Ausgangslage

Die SSD war bereits als ext4 formatiert und hatte ein eigenes Label erhalten.

Mit

lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS

ließen sich Dateisystem, Label und UUID anzeigen.

Beispielsweise:

sdb1
ext4
DatenSSD
12f74ace-32c3-4947-8da2-e98697034c0a

Die UUID ist dabei wichtiger als der Gerätename.

Warum nicht einfach /dev/sdb1 verwenden?

Gerätenamen wie

/dev/sda1
/dev/sdb1
/dev/sdc1

können sich ändern.

Welche Platte beim Start welchen Buchstaben erhält, sollte deshalb nicht die Grundlage für einen dauerhaften Mount sein.

Eine UUID identifiziert dagegen das Dateisystem selbst.

Deshalb wurde die Platte in /etc/fstab über ihre UUID eingetragen.

1. Mountpoint anlegen

Die Datenplatte sollte dauerhaft unter einem Verzeichnis innerhalb von /mnt erreichbar sein.

Beispiel:

sudo mkdir -p /mnt/daten

Der Name ist frei wählbar.

2. UUID ermitteln

Die benötigte UUID lässt sich beispielsweise mit lsblk anzeigen:

lsblk -o NAME,FSTYPE,LABEL,UUID,MOUNTPOINTS

Entscheidend ist die UUID der gewünschten ext4-Partition.

3. /etc/fstab ergänzen

Der verwendete Eintrag hatte folgendes Schema:

UUID=12f74ace-32c3-4947-8da2-e98697034c0a /mnt/daten ext4 defaults,nofail,x-gvfs-show 0 2

Natürlich muss die UUID durch die UUID des eigenen Dateisystems ersetzt werden.

Die Felder bedeuten:

UUID=...

Das einzubindende Dateisystem.

/mnt/daten

Der gewünschte Mountpoint.

ext4

Das verwendete Dateisystem.

defaults

Normale Standard-Mountoptionen.

nofail

Der Rechner soll weiterhin booten können, wenn die Platte einmal nicht verfügbar ist.

x-gvfs-show

Das Laufwerk soll von GVfs-basierten Desktop-Dateimanagern angezeigt werden.

0 2

Die üblichen Werte für Dump und Dateisystemprüfung eines zusätzlichen ext4-Datenträgers.

4. systemd über die Änderung informieren

Nach einer Änderung an /etc/fstab wurde ausgeführt:

sudo systemctl daemon-reload

Damit werden die aus /etc/fstab generierten Mount-Units neu eingelesen.

5. Mount testen

Nach der Einrichtung sollte kontrolliert werden, ob die Partition tatsächlich am vorgesehenen Ort hängt.

Zum Beispiel:

findmnt /mnt/daten

oder:

lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS

Der gewünschte Mountpoint sollte jetzt bei der Partition erscheinen.

Warum nofail sinnvoll ist

Ohne nofail kann eine in /etc/fstab eingetragene, aber nicht verfügbare Datenplatte den Bootvorgang unnötig verzögern oder Probleme verursachen.

Bei einer zusätzlichen Datenplatte bestand dafür kein Grund.

Deshalb:

nofail

Das Root-Dateisystem gehört natürlich in eine andere Kategorie.

Warum x-gvfs-show?

Ein Mount unter

/mnt/daten

ist technisch auch ohne x-gvfs-show verfügbar.

Für einen Desktop-Rechner ist es aber praktisch, wenn das Laufwerk zusätzlich im Dateimanager erscheint.

Dafür wurde verwendet:

x-gvfs-show

lost+found ist normal

Nach der Einrichtung einer ext4-Partition erschien im Wurzelverzeichnis:

lost+found

Das ist kein Überbleibsel alter Dateien und kein Fehler.

lost+found gehört zu ext-Dateisystemen und kann von Dateisystemprüfungen verwendet werden, um gefundene, aber nicht mehr korrekt zuordenbare Dateisystemobjekte abzulegen.

Der Ordner sollte einfach bleiben.

Fertiger fstab-Eintrag

Das verwendete Muster lautet:

UUID=DEINE-UUID /mnt/daten ext4 defaults,nofail,x-gvfs-show 0 2

Danach:

sudo systemctl daemon-reload

und anschließend kontrollieren:

findmnt /mnt/daten

Fazit

Für eine zusätzliche interne Linux-Datenplatte hat sich diese Kombination bewährt:

ext4
+
UUID statt /dev/sdX
+
fester Mountpoint unter /mnt
+
nofail
+
x-gvfs-show

Damit ist die Platte nach dem Start zuverlässig am gleichen Pfad verfügbar, ohne dass ein wechselnder Gerätename wie /dev/sdb1 relevant wird.

Und sie bleibt trotzdem komfortabel im Desktop-Dateimanager sichtbar.

Bevor man sie löscht und als Linux-Datenträger weiterverwendet, sollte man eindeutig klären:

Bootet das aktuelle Linux wirklich von einem anderen Datenträger?

Genau diese Prüfung war in meinem Fall notwendig, bevor eine alte Windows-SSD vollständig neu verwendet werden konnte.

Das Problem

Auf dem Rechner waren mehrere Laufwerke vorhanden:

• eine NVMe-SSD mit dem aktuellen Linux-System
• eine weitere SSD mit Daten
• eine ältere SSD mit ehemaligen Windows-Partitionen
• eine zusätzliche alte NTFS-Festplatte

Die frühere Windows-SSD enthielt unter anderem:

System-reserviert
Datensicherung

Die Bezeichnung System-reserviert ist ein guter Grund, nicht einfach alles zu löschen.

Zuerst musste geklärt werden, ob diese Partition noch irgendeine Rolle für den aktuellen Bootvorgang spielte.

1. Alle Datenträger anzeigen

Eine übersichtliche Darstellung liefert:

lsblk -e7 -o NAME,PATH,SIZE,MODEL,FSTYPE,LABEL,PARTLABEL,UUID,MOUNTPOINTS

Interessant sind vor allem:

NAME
MODEL
FSTYPE
LABEL
UUID
MOUNTPOINTS

So lässt sich zunächst unterscheiden:

• Welche Platte enthält Linux?
• Welche Partition ist als / eingehängt?
• Welche Platte enthält noch NTFS?
• Gibt es alte Windows-Systempartitionen?

Zusätzlich kann man die Partitionstabellen ansehen:

sudo fdisk -l

Bei mehreren ähnlich großen SSDs ist die Modellbezeichnung besonders hilfreich.

2. Prüfen, wo das Root-Dateisystem liegt

Entscheidend ist zunächst die Linux-Systempartition:

findmnt -no SOURCE,FSTYPE,TARGET /

Eine typische Ausgabe könnte beispielsweise so aussehen:

/dev/nvme0n1p5 ext4 /

Damit ist klar:

Das laufende Linux befindet sich auf dieser Partition.

Das sagt allerdings noch nicht zwingend, wo die für den UEFI-Boot benötigte EFI-Systempartition liegt.

3. EFI-Partition prüfen

Bei einem UEFI-System:

findmnt /boot/efi

Damit lässt sich feststellen, welches Gerät aktuell unter

/boot/efi

eingehängt ist.

Im konkreten Fall lag auch die EFI-Partition auf derselben NVMe-SSD wie das aktuelle Linux-System.

Damit sprach bereits sehr viel dafür, dass die alte Windows-SSD nicht mehr zum Booten benötigt wurde.

4. UEFI-Boot-Einträge kontrollieren

Zur zusätzlichen Absicherung:

sudo efibootmgr -v

efibootmgr zeigt die im UEFI gespeicherten Boot-Einträge.

Interessant sind insbesondere:

BootCurrent
BootOrder

und die Gerätepfade der einzelnen Boot-Einträge.

Im untersuchten System zeigte der aktive Linux-Boot-Eintrag auf die EFI-Partition der NVMe-SSD.

Die alte Windows-SSD tauchte dort nicht als benötigter aktueller Boot-Datenträger auf.

5. /etc/fstab kontrollieren

Eine weitere wichtige Kontrolle:

grep -Ev '^\s*#|^\s*$' /etc/fstab

Damit werden Kommentare und Leerzeilen ausgeblendet.

In meinem Fall enthielt /etc/fstab Einträge für:

• die Linux-Systempartition
• die EFI-Partition
• einen zusätzlichen Linux-Datenträger

Die alte Windows-SSD war dort nicht eingebunden.

Auch das bestätigte:

Das laufende System war nicht auf sie angewiesen.

6. Erst danach löschen

Die Kombination aus

lsblk
findmnt
efibootmgr
/etc/fstab

lieferte schließlich ein konsistentes Bild:

Linux-System
      ↓
NVMe-SSD

EFI-Systempartition
      ↓
dieselbe NVMe-SSD

aktiver UEFI-Boot-Eintrag
      ↓
EFI-Partition der NVMe-SSD

alte Windows-SSD
      ↓
weder Root noch EFI noch fstab-Abhängigkeit

Erst danach wurde die alte Windows-Partitionierung entfernt und die SSD als Linux-Datenträger neu eingerichtet.

Warum die Prüfung wichtig ist

Eine kleine Partition mit Namen wie

System-reserviert
EFI System
Boot
Recovery

sollte man nicht allein aufgrund ihres Alters löschen.

Gerade Rechner, auf denen Windows und Linux nacheinander oder parallel installiert waren, können Boot-Dateien auf einem anderen Laufwerk enthalten als das eigentliche Betriebssystem.

Das Betriebssystem kann also beispielsweise auf

/dev/nvme0n1

liegen, während der Rechner theoretisch trotzdem eine EFI-Partition auf

/dev/sda

verwenden könnte.

Deshalb ist es sinnvoll, nicht nur das Root-Dateisystem zu prüfen.

Minimaler Prüfablauf

Vor dem Löschen eines alten Systemdatenträgers würde ich mindestens diese vier Prüfungen durchführen:

lsblk -e7 -o NAME,PATH,SIZE,MODEL,FSTYPE,LABEL,UUID,MOUNTPOINTS

findmnt -no SOURCE,FSTYPE,TARGET /

findmnt /boot/efi

sudo efibootmgr -v

Zusätzlich:

grep -Ev '^\s*#|^\s*$' /etc/fstab

Wenn alle Ergebnisse eindeutig auf einen anderen Datenträger zeigen, ist die Grundlage vorhanden, die alte Platte anschließend neu zu verwenden.

Fazit

Der gefährliche Teil beim Wiederverwenden einer alten Windows-SSD ist nicht das Formatieren selbst.

Der gefährliche Teil ist die Frage:

Bin ich wirklich sicher, dass mein Rechner sie nicht mehr zum Booten benötigt?

Mit

lsblk
findmnt
efibootmgr
fstab

lässt sich diese Frage unter Linux relativ zuverlässig beantworten.

Erst wenn Root-Dateisystem, EFI-Partition, UEFI-Boot-Eintrag und dauerhafte Mounts eindeutig geklärt sind, sollte eine alte Windows-Systempartition entfernt werden.

In meinem Fall sollte eine solche alte NTFS-Platte zunächst einfach leergeräumt und anschließend für Linux neu formatiert werden. Beim Kopieren größerer Datenbestände traten jedoch wiederholt Input/output error (5) auf. Damit wurde aus einer simplen Aufräumaktion eine Datenrettung.

Dieser Artikel beschreibt den tatsächlich verwendeten Ablauf unter Linux Mint:

1. Datenträger eindeutig identifizieren
2. sicherstellen, dass keine Boot- oder Systempartition gelöscht wird
3. lesbare Daten mit rsync kopieren
4. den Gesundheitszustand mit SMART prüfen
5. beschädigte Einzeldateien mit GNU ddrescue retten
6. gerettete Dateien überprüfen
7. die defekte Platte anschließend ausmustern

Problem

Die alte Platte war noch als NTFS formatiert und enthielt mehrere hundert Gigabyte an Backups, Bildern, Videos und sehr vielen kleinen Webdateien.

Ein Kopierversuch mit rsync lief zunächst normal, meldete dann aber Fehler wie:

rsync: [sender] read errors mapping "...": Input/output error (5)

ERROR: ... failed verification -- update discarded.

rsync error: some files/attrs were not transferred
(code 23)

Wichtig dabei: rsync konnte den weit überwiegenden Teil der Daten weiterhin kopieren. Betroffen waren einzelne Dateien.

Bevor man in so einer Situation die Platte repariert, neu formatiert oder weitere große Kopieraktionen startet, sollte geklärt werden, ob ein Dateisystemproblem oder ein physischer Plattenschaden vorliegt.

1. Festplatten eindeutig identifizieren

Bevor irgendein destruktiver Befehl ausgeführt wird, sollte klar sein, welches Gerät welches ist.

Eine gute Übersicht liefert:

lsblk -e7 -o NAME,PATH,SIZE,MODEL,FSTYPE,LABEL,PARTLABEL,UUID,MOUNTPOINTS

Zusätzlich:

sudo fdisk -l

Für das aktuell laufende Linux-System ist wichtig:

findmnt -no SOURCE,FSTYPE,TARGET /
findmnt /boot/efi

Damit lässt sich feststellen, auf welcher Partition / liegt und von welcher EFI-Partition das System bootet.

Auch /etc/fstab sollte kontrolliert werden:

grep -Ev '^\s*#|^\s*$' /etc/fstab

Und bei einem UEFI-System:

sudo efibootmgr -v

Im konkreten Fall konnte so eindeutig festgestellt werden:

• Linux lag auf einer NVMe-SSD.
• Die aktive EFI-Partition lag ebenfalls dort.
• Eine zusätzliche NTFS-Partition namens System-reserviert gehörte zum früheren Windows-System und wurde vom aktuellen Linux nicht verwendet.
• Die zu rettende alte Backupplatte war ein anderer Datenträger.

Diese Prüfung war entscheidend. Ein wipefs oder mkfs auf der falschen Platte wäre nicht reparabel gewesen.

2. Viele Dateien besser mit rsync als per Dateimanager kopieren

Bei Verzeichnissen mit sehr vielen kleinen Dateien kann ein grafischer Dateimanager schnell unübersichtlich oder langsam werden.

Für einzelne Verzeichnisse eignet sich rsync:

rsync -rlt --partial --info=progress2 \
"/media/user/ALTE_PLATTE/Quellordner" \
"/mnt/NEUE_PLATTE/Zielordner/"

Die verwendeten Optionen:

-r                  Verzeichnisse rekursiv kopieren
-l                  symbolische Links erhalten
-t                  Zeitstempel erhalten
--partial           angefangene Dateien bei Abbruch behalten
--info=progress2    Gesamtfortschritt anzeigen

Mehrere Ordner lassen sich in einem Lauf angeben:

rsync -rlt --partial --info=progress2 \
"/media/user/ALTE_PLATTE/Ordner1" \
"/media/user/ALTE_PLATTE/Ordner2" \
"/media/user/ALTE_PLATTE/Ordner3" \
"/mnt/NEUE_PLATTE/Sicherung/"

Ein Vorteil von rsync: Der gleiche Befehl kann später erneut gestartet werden. Bereits erfolgreich kopierte Dateien müssen dann nicht komplett erneut übertragen werden.

Nicht jede Lesewarnung bedeutet automatisch Datenverlust

Bei der defekten Platte tauchten manche Dateien während des Kopierens zunächst mit einem Lesefehler auf, konnten bei einem späteren Versuch aber doch übertragen werden.

Entscheidend waren deshalb vor allem Meldungen wie:

failed verification -- update discarded

Diese Dateien waren tatsächlich nicht erfolgreich kopiert worden.

3. SMART prüfen – und nicht nur auf „PASSED“ schauen

Nach den ersten I/O-Fehlern wurde die Platte mit smartctl untersucht:

sudo smartctl -a /dev/sdX

Falls das Programm fehlt:

sudo apt install smartmontools

Interessant waren insbesondere diese Werte:

Reallocated_Sector_Ct
Current_Pending_Sector
Offline_Uncorrectable
Power_On_Hours

Bei der untersuchten Platte wurden unter anderem gemeldet:

Reallocated_Sector_Ct   151
Current_Pending_Sector  1114
Offline_Uncorrectable   561
Power_On_Hours          69315

Gleichzeitig stand weiter oben:

SMART overall-health self-assessment test result: PASSED

Das ist ein gutes Beispiel dafür, warum man sich nicht allein auf PASSED verlassen sollte.

Die Kombination aus

• wiederholten echten I/O-Lesefehlern,
• bereits umverteilten Sektoren,
• sehr vielen noch ausstehenden problematischen Sektoren,
• nicht korrigierbaren Sektoren

war hier ein klarer Grund, die Platte nicht mehr weiterzuverwenden.

Die Konsequenz war deshalb:

Nicht reparieren und anschließend neu formatieren, sondern zuerst möglichst viele Daten retten und die Platte danach ausmustern.

4. Zuerst die noch lesbaren Daten retten

Bei einer sichtbar ausfallenden Festplatte ist es sinnvoll, nicht sofort stundenlange Tests oder Reparaturläufe zu starten.

Im konkreten Fall wurden zunächst die noch lesbaren Verzeichnisse mit rsync auf andere Datenträger kopiert.

Erst danach wurden die wenigen Dateien bearbeitet, die rsync nicht lesen konnte.

Damit musste die alte Platte nicht mehrfach vollständig durchgelesen werden.

5. Beschädigte Einzeldateien mit GNU ddrescue retten

Für die verbleibenden Dateien kam GNU ddrescue zum Einsatz.

Installation:

sudo apt install gddrescue

Anschließend wurde eine kleine Shell-Funktion verwendet:

BASE="/media/user/ALTE_PLATTE"
OUT="/mnt/NEUE_PLATTE/Rettung"

recover() {
    rel="$1"
    src="$BASE/$rel"
    dst="$OUT/$rel"

    mkdir -p "$(dirname "$dst")"

    echo
    echo "=== RETTE: $rel ==="

    ddrescue -n "$src" "$dst" "$dst.ddrescue.map"
    ddrescue -r3 "$src" "$dst" "$dst.ddrescue.map"
}

Eine Datei konnte damit einfach so bearbeitet werden:

recover "Backup/Bilder/beispiel.jpg"

Zuerst versucht

ddrescue -n

möglichst viel ohne aggressive Wiederholungsversuche zu lesen.

Danach versucht

ddrescue -r3

problematische Bereiche bis zu drei weitere Male zu lesen.

Die Map-Datei merkt sich, welche Bereiche bereits erfolgreich gerettet wurden.

6. Was ddrescue noch retten konnte

Die Ergebnisse waren sehr unterschiedlich.

Einige Dateien, die rsync überhaupt nicht mehr kopieren konnte, ließen sich mit ddrescue anschließend zu

100.00%

wiederherstellen.

Bei anderen blieben wenige Kilobyte defekt.

Beispielsweise konnten große MP4-Videos bis auf ungefähr 8 KB gerettet werden. Andere Dateien blieben zu 94, 97 oder über 99 Prozent lesbar.

Es gab aber auch Dateien, bei denen

rescued: 0 B
pct rescued: 0.00%

stehen blieb.

Und bei zwei Dateien konnte ddrescue nicht einmal die Quelldatei öffnen:

Can't open input file: Input/output error

Das zeigt eine Grenze der Rettung auf Dateiebene:

Wenn bereits die für das Öffnen einer Datei benötigten Dateisysteminformationen nicht mehr gelesen werden können, kann ein dateibasierter ddrescue-Aufruf nicht helfen.

Für wichtige Daten wäre dann eine sektorweise Rettung des gesamten Datenträgers ein anderer Ansatz gewesen. Für die betreffenden unwichtigen Altdateien wurde darauf verzichtet.

7. Gerettete Dateien prüfen

Ein Wert von 99 Prozent sagt noch nicht, ob eine Datei praktisch verwendbar ist.

Deshalb wurden unterschiedliche Dateitypen anschließend geprüft.

Dateityp erkennen

file /pfad/zur/datei

Bei erfolgreich geretteten Dateien ergaben sich beispielsweise wieder plausible Typen wie:

JPEG image data
PDF document
Microsoft Word 2007+
Composite Document File V2 Document

Das ist allerdings nur ein erster Test.

8. DOCX-Dateien überprüfen

DOCX-Dateien sind intern ZIP-Archive.

Deshalb kann man ihre Struktur testen:

unzip -t dokument.docx

Eine vollständig gerettete Datei lieferte:

No errors detected in compressed data

Bei beschädigten Dateien zeigte unzip dagegen beispielsweise:

invalid compressed data to inflate
bad zipfile offset

Reparaturversuch mit zip -FF

Eine Kopie des beschädigten Dokuments kann als ZIP behandelt werden:

cp dokument.docx dokument_beschaedigt.zip

Dann:

zip -FF dokument_beschaedigt.zip --out dokument_repariert.zip

Anschließend:

unzip -t dokument_repariert.zip

Das kann Teile eines DOCX retten.

Allerdings gibt es einen wichtigen Fallstrick:

Ein anschließend fehlerfreies ZIP bedeutet nicht automatisch ein repariertes Word-Dokument.

Bei einem Test fehlten nach der Reparatur ausgerechnet:

[Content_Types].xml
_rels/.rels
word/_rels/document.xml.rels
word/document.xml

word/document.xml enthält den eigentlichen Dokumenttext.

Der ZIP-Container war danach zwar fehlerfrei, der Dokumentinhalt aber trotzdem verloren.

Eingebettete Bilder konnten dagegen noch extrahiert werden:

mkdir -p gerettete_medien

unzip -j dokument_repariert.zip \
'word/media/*' \
-d gerettete_medien

9. PDFs prüfen

Für PDFs wurde pdfinfo verwendet:

pdfinfo dokument.pdf

Bei teilweise beschädigten Rettungen konnten trotzdem korrekte Metadaten und Seitenzahlen gelesen werden.

Beispielsweise wurden Dateien trotz weniger fehlender Kilobyte noch sauber als fünf- beziehungsweise mehrseitige PDFs erkannt.

Das war ein gutes Indiz dafür, dass zumindest die grundlegende PDF-Struktur erhalten geblieben war.

10. Bilder wirklich decodieren

file kann eine beschädigte Datei weiterhin als JPEG erkennen.

Deshalb reicht

file bild.jpg

nicht immer aus.

Mit ffmpeg lässt sich versuchen, das Bild vollständig zu decodieren:

ffmpeg -v error -i bild.jpg -f null -

Im Test gab es drei unterschiedliche Ergebnisse:

Keine Ausgabe

Das Bild ließ sich vollständig decodieren.

Kleine Warnung

overread 8

Das Bild war sichtbar beschädigt, ließ sich aber noch anzeigen.

Vollständiger Decoderfehler

No JPEG data found in image
Invalid data found when processing input

Diese Datei war praktisch nicht mehr nutzbar.

11. Videos prüfen: ffprobe reicht nicht immer

Die geretteten MP4-Dateien wurden zuerst mit ffprobe geprüft:

ffprobe -v error video.mp4

Bei allen drei Testdateien blieb die Ausgabe leer.

Das bedeutet: Der Container konnte gelesen werden.

Für einen vollständigen Test wurde anschließend das gesamte Video decodiert:

ffmpeg -v error -i video.mp4 -f null -

Bei einem vollständig geretteten Video blieb die Ausgabe wiederum leer.

Bei zwei anderen Videos erschienen einzelne Meldungen wie:

cabac decode of qscale diff failed
error while decoding MB ...

Die Videos ließen sich trotzdem abspielen. Durch die wenigen nicht lesbaren Kilobyte waren lediglich einzelne Bildbereiche beziehungsweise Frames beschädigt.

Damit waren sie für den konkreten Zweck ausreichend gerettet.

12. Gerettete Dateien erst separat behalten

Die ddrescue-Ergebnisse wurden zunächst bewusst in einem eigenen Rettungsordner gespeichert.

Beispiel:

/mnt/NEUE_PLATTE/Rettung/

Erst nach Prüfung wurden brauchbare Dateien an ihre endgültigen Positionen kopiert.

Das verhindert, dass eine möglicherweise schlechtere Rettungsfassung versehentlich eine bereits vorhandene Datei überschreibt.

Auch bei Videos wurden zunächst beide Fassungen behalten:

video.mp4
video_rsync-alt.mp4

Erst nach dem Abspielen und Testen wurde die schlechtere Version gelöscht.

13. Rettungsreste aufräumen

Nach Abschluss der Rettung können die Map-Dateien entfernt werden, sofern definitiv keine weiteren Rettungsversuche geplant sind:

find /mnt/NEUE_PLATTE/Rettung \
-type f -name '*.ddrescue.map' -delete

Temporäre Reparaturarchive können ebenfalls gelöscht werden:

rm dokument_beschaedigt.zip
rm dokument_repariert.zip

Die tatsächlich geretteten Dateien sollten vorher natürlich an ihre endgültigen Speicherorte kopiert worden sein.

14. Defekte Platte aushängen

Wenn alles Wichtige kopiert wurde:

sudo umount /media/user/ALTE_PLATTE

Danach kontrollieren:

lsblk -o NAME,SIZE,MODEL,FSTYPE,LABEL,MOUNTPOINTS /dev/sdX

Wenn bei der Partition kein Mountpoint mehr angezeigt wird, ist sie sauber ausgehängt.

Im beschriebenen Fall wurde die Platte danach nicht neu formatiert, sondern aus dem Rechner ausgebaut.

Die SMART-Werte und die reproduzierbaren I/O-Fehler waren zu eindeutig, um sie noch als Datenträger weiterzuverwenden.

Was ich aus dem Fall mitnehme

Der ursprüngliche Plan war simpel:

Daten herunterkopieren, NTFS löschen, ext4 formatieren.

Die Kopierfehler haben den Ablauf jedoch sinnvoll verändert.

Der entscheidende Workflow war am Ende:

Datenträger eindeutig identifizieren
        ↓
wichtige Daten mit rsync kopieren
        ↓
I/O-Fehler feststellen
        ↓
SMART-Werte prüfen
        ↓
keine Reparatur oder Formatierung mehr
        ↓
problematische Einzeldateien mit ddrescue retten
        ↓
Dateien je nach Format prüfen
        ↓
brauchbare Rettungen einsortieren
        ↓
defekte HDD ausmustern

Besonders hilfreich war die Kombination aus Werkzeugen:

lsblk / findmnt / efibootmgr
        → richtige Platte identifizieren

rsync
        → möglichst viel normal kopieren

smartctl
        → Hardwarezustand einschätzen

ddrescue
        → problematische Einzeldateien gezielt retten

file / unzip / pdfinfo / ffprobe / ffmpeg
        → prüfen, ob die Rettung tatsächlich brauchbar ist

Der vielleicht wichtigste Punkt: Ein SMART-Status PASSED bedeutet nicht automatisch, dass eine Festplatte gesund ist. Wenn gleichzeitig hunderte oder tausende problematische Sektoren und reale I/O-Fehler auftreten, sollte man die einzelnen SMART-Werte und das tatsächliche Verhalten der Platte ernst nehmen.

Und ebenso wichtig: Eine Datei ist nicht automatisch intakt, nur weil sie zu 99 Prozent gerettet wurde oder file noch den richtigen Dateityp erkennt. Erst ein formatgerechter Test zeigt, wie viel wirklich noch verwendbar ist.