[Gelöst] Kein Zugriff auf eigentlich erfolgreich wiederhergestellte Partition

Norbert

Moderator
Teammitglied
Gerade ist mir ein Ding passiert, das mir ja in 35 Jahren Computerpraxis noch nie untergekommen ist.

Zum Test habe ich aus einer Datensicherung des alten PCs mittels Aomei Backupper sämtliche Partitionen als virtuelle Laufwerke gemountet und konnte auch problemlos auf fast alle zugreifen und Daten daraus kopieren. Nur eine Partition stellte sich quer, obwohl auch sie sich mounten ließ.

Die habe ich mir dann nochmal einzeln vorgenommen (Bild 1) und nicht nur als virtuelles Laufwerk eingebunden (Bild 2: "J"), sondern auch auf einer temporär eingerichteten Festplattenpartition wieder hergestellt (Bild 2: "H"). Es dauerte erwartungsgemäß auch einige Minuten, bis die 70 GB auf der Platte waren, es schien also alles normal zu verlaufen. Wie aber im Bild 2 zu sehen, wird in beiden Fällen kein Balken mit Partitionsgröße und Speicherbelegung angezeigt, das Teil soll also angeblich die Größe 0 haben. Außerdem ist die Volumebezeichnung falsch, sie müsste "Programme" lauten. Der Versuch, eines der beiden Laufwerke zu öffnen, bringt den Fehler "Zugriff verweigert" mit dem Titel, dass der Pfad nicht verfügbar sei (Bild 3).

Anschließend habe ich mir die Sache in der Datenträgerverwaltung angeschaut (Bild 4) und darin die Fehlerüberprüfung (Chkdsk) gestartet. Und o Wunder, das Protokoll in der Ereignisanzeige sagt mir, dass alles okay wäre und keine Fehler in über 100.000 Dateien gefunden wurden (Bild 5).

Ja Sakrafix, wie komme ich denn jetzt an diese Daten dran? Wenn das in einem echten Notfall passiert, na dann gute Nacht.

(Windows 10 Pro Version 1909, Build 18363.900)
 

Anhänge

  • Partitions-Image.png
    Partitions-Image.png
    441,4 KB · Aufrufe: 302
  • Image zum Test wieder hergestellt.png
    Image zum Test wieder hergestellt.png
    103,9 KB · Aufrufe: 300
  • Zugriff verweigert.png
    Zugriff verweigert.png
    3,1 KB · Aufrufe: 257
  • Datenträgerverwaltung.png
    Datenträgerverwaltung.png
    94 KB · Aufrufe: 297
  • Chkdsk in Datenträgerverwaltung ausgeführt.png
    Chkdsk in Datenträgerverwaltung ausgeführt.png
    89,1 KB · Aufrufe: 229
Kannst du den nicht zugewiesenen Speicherplatz auf diese Partition erweitern? Eventuell bringt dass wieder den Zugriff darauf.
Mit einer Bootcd, wie zum Beispiel Hirens Boot CD, kommt man im Normalfall wieder an die Daten.
 
Kannst du den nicht zugewiesenen Speicherplatz auf diese Partition erweitern? Eventuell bringt dass wieder den Zugriff darauf.
Könnte ich, aber ich wüsste nicht, warum damit der Zugriff möglich werden sollte. Ich habe extra die Partition genauso wiederhergestellt, wie sie im Original auf dem alten PC auch existiert.

edit:
Habe mal die Partition mit dem unzugeordneten Platz erweitert, hatte ja nur Sekunden gedauert. Hat erwartungsgemäß nichts gebracht.

edit2:
"diskpart" in der Kommandozeile zeigt auch keine Fehler an und listet das Volume 3 "Programme", Laufwerk H, als völlig okay auf.
 
Zuletzt bearbeitet:
Ist nur eine schwache Hoffnung, aber schau dir doch mal an, welchem Nutzer die Partition gehört und wie die Zugriffsrechte geregelt sind.
 
Moin Martin,

sie unterscheidet sich in der Hinsicht nicht von den anderen 4 NTFS-Partitionen. Sogar die virtuell gemountete Bootpartition mit Windows 7 ließ sich problemlos lesen und Daten daraus kopieren, mit den üblichen Zugriffsbeschränkungen bei den Systemordnern. Aber selbst wenn ich keinerlei Rechte hätte auf die Daten zuzugreifen, so müsste diese normale Datenpartition physikalisch doch nicht nur in der Datenträgerverwaltung, sondern auch im Explorer zu sehen sein. Dort sieht sie jedoch aus wie ein Wechseldatenträger, in das kein Medium eingelegt ist. Sowohl beim gemounteten Image ("J:") als auch der physischen Partition ("H:"). Sogar der grüne Balken läuft oben im Explorer, wenn ich das Volume anklicke, so als ob er auf das Einlegen eines Mediums wartete, obwohl ja zugleich die Fehlermeldung kommt. Und wie kann denn eine Partition an sich einen Besitzer haben, das geht doch gar nicht, oder?

Die Windows 10 Installation hier auf dem neuen PC ist noch ganz frisch (am Sonntag eingerichtet) und ich habe noch einen Haufen an Installationen von Anwenderprogramm vor mir. So ist leider auch der Aomei Partitionsmanager noch nicht drauf, mit dem ich mal den Partitionstyp auslesen könnte. Vieleicht hängt ja hier der Hase im Pfeffer. Wobei ich mir aber nicht vorstellen kann, wieso das Image einen anderen Typ gespeichert haben sollte, als es die originale Partition ist. Auf dem alten PC verhält sie sich ja auch ganz normal, siehe oben -> "kein Unterschied zu den anderen".

Wie gesagt, ist das hier einerseits nur ein Test und andererseits kann ich mir etliche einfache Daten schon aus den Images des alten PCs holen, ohne das er laufen muss. Wäre sonst etwas umständlich mit nur einem Monitor und ohne KVM-Switch. Doch wenn der Test schief läuft, kann ich mir später nie sicher sein, dass die Images im Falle eines eventuellen Daten-GAUs auch ordentlich funktionieren.
 
Das hilft natürlich auch nicht bei dem Problem, aber dein Erlebnis ist einer der Gründe, warum ich Image-Backups nur zu Sicherung von Systemzuständen verwende und empfehle. Sie sind einfach zu anfällig. Reine Datenbackups werden bei mir Datei für Datei erledigt.
 
Reine Datenbackups werden bei mir Datei für Datei erledigt.
Ja, das mache ich auch regelmäßig und fast täglich, bei Bedarf sogar alle paar Stunden. Und das meistens (bei wichtigen Daten) mehrfach: Einmal auf eine interne Festplatte zur schnellen Wiederherstellung, wenn ich selber mal Bockmist baue, dann noch auf eine externe Platte, und sehr oft bearbeitete (Projekt-)Dateien auch noch auf einen USB-Stick. Außerdem läuft hier noch das Aorus Smart Backup (Gigabyte) einmal jede Stunde ebenfalls auf die interne Backup-Platte, ob das besser oder schlechter als die gleiche in Windows 10 enthaltene Lösung ist, weiß ich noch nicht und werde es ja sehen.

Die Images sollen zumeist nur zur Grundwiederherstellung des Systems dienen, alle paar Monate wird aber auch mal wieder eine Sicherung des Gesamtsystems als Image gemacht.
 
Evtl. hilft es "chkdsk" mit Parametern auszuführen für eine tiefgreifendere Analyse und Fehlerbeseitigung:

Das "Ausführen"-Fenster öffnen. Dazu die Windows-Taste auf der Tastatur drücken und halten und dann "R" drücken.
Im jetzt angezeigten Textfeld "cmd" eingeben und mit "OK" oder über die "Enter"-Taste bestätigen.
Im nun angezeigten Fenster den Befehl "chkdsk X: /f /r" eingeben.
(Achtung: anstelle des "X" muss natürlich der Buchstabe des betroffenen Laufwerks eingegeben werden; bei der Texteingabe die Leerzeichen nicht vergessen)
Auf der Tastatur die "Enter"-Taste drücken.

Windows überprüft nun in mehreren Schritten die ausgewählte Partition auf Fehler.
Bei Bedarf werden dabei sofort diverse Korrekturen durchgeführt, die in den entsprechenden Protokolltexten angezeigt werden.
Während dieses Tests ist die Verwendung der Festplatte zwar möglich, besser ist es aber, darauf zu verzichten.
Während der Überprüfung kann teilweise der Eindruck entstehen, dass überhaupt nichts passiert, aber davon sollte man sich nicht irritieren lassen, denn im Hintergrund arbeitet das System weiter.
Nach Beendigung des kompletten Vorgangs wird eine Zusammenfassung der Ergebnisse sowie der durchgeführten Reparaturarbeiten angezeigt.
 
Die chkdsk-Prüfung ohne den Reparaturparametern habe ich ja schon in der Datenträgerverwaltung laufen lassen, ohne negativen Befund, wie du oben im Bild 5 sehen kannst. Und obwohl reine Analysefunktionen mit "diskpart" zwar funktionierten, befürchte ich, dass es mit "chkdsk h: /f /r" auf der Kommandozeile nicht gehen wird, da ja auch andere Befehle wie z.B. "cd h:" die Fehlermeldung eines ungültigen Pfades oder "kein Zugriff" ausgelöst hatten. Außerdem habe ich die physikalische Testpartition bereits gelöscht und wieder dem Laufwerk E: zugeführt. Und "/f /r" geht auf einem virtuellen Laufwerk natürlich nicht, wenn ich das Image einbinde, das ist ja read only. :D

PS: Du brauchst mir nicht zu sagen, wie die cmd-Shell gestartet wird, schließlich habe ich meine MSDOS- und Win9x-Zeiten nicht vergessen. :) Sogar edlin und debug sind mir noch bekannte Begriffe. :ROFLMAO:

Und guck mal, was ich da ganz oben festgetackert habe: ;)
 

Anhänge

  • OpenShell.png
    OpenShell.png
    70,5 KB · Aufrufe: 268
Zuletzt bearbeitet:
Ist nur eine schwache Hoffnung, aber schau dir doch mal an, welchem Nutzer die Partition gehört und wie die Zugriffsrechte geregelt sind.
So, das ließ mir natürlich keine Ruhe und ich habe die Partition nochmal auf der Festplatte wie oben gezeigt wiederhergestellt, um die Benutzerrechte der Daten (nicht "Partition") zu prüfen.

Da der Zugriff nur über die Datenträgerverwaltung möglich war, habe ich mir dort mal die Kontextmenüeinträge genauer angeschaut, was die mir eigentlich noch so bieten. Von dort heraus habe ich nun erstmal die Indexierung abgeschaltet, was auch tatsächlich ohne Fehlermeldung durchlief. Anschließend die Besitzrechte geprüft und siehe da, der Benutzername war in seiner Fortsetzung mit einem Schlüssel ergänzt, für den es überhaupt keinen Benutzer auf diesem PC gibt. War wahrscheinlich der Benutzer des alten PCs, natürlich auch ich selber, aber mit einem anderen Schlüssel, der bei der Installation von Windows 10 auf dem neuen PC neu erstellt wurde. Diesen alten Benutzer habe ich gelöscht und den Besitz für mich mit dem gültigen Objekt übernommen.

Bingo, das war's, die Partition war damit sichtbar und alle Daten ließen sich erreichen. Alle noch benötigten Daten habe ich sodann problemlos dorthin kopieren können, wo ich sie haben will. Im Anschluss die nicht mehr benötigte Partition gelöscht und den frei gewordenen Speicher wieder mit der Partition davor zusammengeführt.

Möglicherweise hing das Problem damit zusammen, dass diese Partition auf dem bisherigen PC den Benutzer (ich) mit sämtlichen "Eigene Dateien" enthielt, die ich damals direkt nach der Windows 7 Installation auf das andere Laufwerk verschoben hatte. Interessant an der Aktion war auch, dass alle in der Datenträgerverwaltung aufgerufenen Dialoge genau die gleichen waren, als hätte ich sie auf die herkömmliche Art gestartet. In letzterem Fall wurde jedoch kein Laufwerk erkannt und eine Fehlermeldung ausgegeben, wohingegen bei deren Start über Kontextmenüs in der Datenträgerverwaltung alle nötigen Aktionen möglich waren.
 
Zuletzt bearbeitet:
Außerdem läuft hier noch das Aorus Smart Backup (Gigabyte) einmal jede Stunde ebenfalls auf die interne Backup-Platte, ob das besser oder schlechter als die gleiche in Windows 10 enthaltene Lösung ist, weiß ich noch nicht und werde es ja sehen.
Jetzt läuft es nicht mehr. Ich habe den Smart Backup abgeschaltet, da es mir bei jedem Start den Fokus vom gerade aktiven Fenster geklaut hatte, obwohl es im Hintergrund lief und gar kein eigenes Fenster öffnete. Bei Vollbildanwendungen wie z.B. den meisten Spielen war das übel, da die Anwendung minimiert wurde und man auf dem Desktop landete. Diese Backuplösung ist also schlechter als die von Windows 10, obwohl sie ansonsten ressourcenschonend und unauffällig funktioniert hatte. Habe stattdessen jetzt doch das Windows-Backup aktiviert und hoffe, dass es nicht den gleichen Unsinn verzapft.

edit:
Nach über 2 Monaten der Umstellung auf die Windows-interne Datensicherung kann ich jetzt sagen, dass sie klaglos und unauffällig funktioniert. Der Fokusklau ist seitdem nie wieder aufgetreten. Der einzige Kritikpunkt ist, dass ihre Konfigurierung im Gegensatz zum Aorus Smart Backup äußerst umständlich ist. Man muss sich durch Menüs, Submenüs und Subsubmenüs hangeln, bis endlich alles wie gewünscht eingestellt ist. Aber das muss man ja zum Glück nicht alle Tage durchführen.
 
Zuletzt bearbeitet:
Oben