Mein APFS-Laufwerk wurde auf meinem Mac plötzlich nicht mehr eingebunden, und ich erhalte ständig den Fehler com.apple.diskmanagement.disenter. Ich brauche Hilfe dabei herauszufinden, was die Ursache ist, ob meine Daten gefährdet sind und welche Schritte ich unternehmen kann, um das Laufwerk sicher einzubinden, ohne das Problem zu verschlimmern.
Ich bin auf macOS in dasselbe Chaos mit dem Fehler disenter geraten, und es fühlte sich weniger wie ein Laufwerksausfall an, sondern eher so, als würde macOS das Einhängen auf Systemebene verweigern. Der Mac erkannte die Hardware. Der Dateisystemdienst beendete den Vorgang nicht, sodass die Festplatte dort nutzlos liegen blieb.
Was bei mir immer wieder passiert ist
Was ich am häufigsten gesehen habe, war, dass fsck im Hintergrund hängen blieb. Wenn du ein Laufwerk trennst, ohne es vorher auszuwerfen, startet macOS normalerweise beim nächsten Verbinden eine Dateisystemprüfung. Auf dem Papier in Ordnung. In der Praxis habe ich erlebt, dass sie sich bei großen ExFAT-Laufwerken und größeren APFS-Volumes ewig aufhängt. Solange sie hängt, bleibt das Laufwerk gesperrt und wird nicht eingebunden.
Die Terminal-Lösung, die ich zuerst ausprobiert habe
Öffnen Sie das Terminal und führen Sie Folgendes aus:
sudo pkill -f fsck
Sie benötigen Ihr Administratorpasswort. Nachdem ich das getan hatte, wurde das Laufwerk sofort mehr als einmal eingebunden. Ein paar Mal wurde es schreibgeschützt wiederhergestellt, was für mich in Ordnung war, da ich nur Dateien herunterladen musste, bevor ich etwas anderes unternahm.
Festplattendienstprogramm, aber in der richtigen Reihenfolge
Dieser Teil wird oft übersehen. Klicken Sie nicht nur auf Erste Hilfe beim ausgegrauten Volume und betrachten Sie es dann als erledigt.
Im Festplattendienstprogramm:
Darstellung > Alle Geräte einblenden
Führen Sie dann Erste Hilfe in dieser Reihenfolge aus:
1. Die physische Festplatte
2. Der Container
3. Das Volume
Ich hatte einen Fall, bei dem der erste Durchlauf fehlschlug, der zweite sich über die Zuordnungstabelle beschwerte und der dritte das Problem schließlich behob. Wenn also einmal ein Fehler auftritt, würde ich dort nicht aufhören. Ein weiterer Durchlauf ändert manchmal das Ergebnis.
Wenn Erste Hilfe aufgibt
Wenn das Festplattendienstprogramm den Exit-Code 8 ausgibt oder meldet, dass das Volume nicht repariert werden kann, würde ich nicht weiter darauf herumhämmern. Das habe ich auf die harte Tour gelernt. Wiederholte Bereitstellungsversuche bei einem beschädigten Dateisystem sind eine schlechte Wette, wenn die Daten wichtig sind.
An diesem Punkt würde ich zur Wiederherstellung wechseln, bevor ich irgendetwas Zerstörerisches tue. Disk Drill hat in einem Fall geholfen, in dem macOS sich weigerte, das Laufwerk überhaupt zu mounten. Es hat die Rohsektoren gescannt und genug von der Ordnerstruktur angezeigt, damit ich die Dateien zuerst auf ein anderes Laufwerk kopieren konnte. Darauf kam es mir an. Daten sichern, später löschen.
Ein merkwürdiges macOS-Verhalten
Ich habe auf neueren macOS-Builds auch eine seltsame systemseitige Lösung beobachtet. Das Abmelden von deinem Account und erneute Anmelden hat manchmal den festgefahrenen DiskManagement-Prozess zurückgesetzt. Das Starten im abgesicherten Modus hat auf meinem Rechner ebenfalls einmal dasselbe bewirkt. Wenn du kurz davor bist, neu zu formatieren, würde ich das zuerst ausprobieren, da es weniger Zeit kostet und deine Dateien nicht anfasst.
Wenn der Fehler com.apple.diskmanagement.disenter lautet, würde ich mir zuerst drei Ursachen ansehen.
- APFS-Metadatenschaden. Der Container- oder Volume-Superblock wird nach einem unsauberen Auswerfen, Absturz oder Stromausfall beschädigt.
- Die macOS-Richtlinie blockiert das Einhängen. Ich habe das nach OS-Updates gesehen, besonders wenn das Laufwerk verschlüsselt war oder einem anderen Mac gehörte.
- Probleme im Hardwarepfad. Schlechte USB-C-Hubs, schwache Kabel und Gehäuse verursachen unvollständige Lesevorgänge. Das Laufwerk wird angezeigt, das Einhängen schlägt fehl.
Ich widerspreche @mikeappsreviewer in einem Punkt leicht. Das Beenden von fsck hilft in manchen Fällen, aber wenn deine APFS-Metadaten bereits instabil sind, ist es riskant, Dinge mitten in der Prüfung zu erzwingen. Wenn die Dateien wichtig sind, beginne mit der Inspektion, nicht mit Zwang.
Was ich tun würde:
Ausführen:
diskutil list
Finde die APFS-Container- und Volume-IDs. Dann ausführen:
diskutil apfs list
Achte auf:
- FileVault-Sperrstatus
- Fusion-Fehlanpassung
- Physical-Store-Fehler
- Snapshot-Auffälligkeiten
- Rollen-Fehlanpassung auf dem Volume
Versuche dann ein manuelles Einhängen im Terminal:
sudo diskutil mount readOnly /dev/diskXsY
Schreibgeschützt ist zuerst sicherer. Wenn es eingehängt wird, kopiere die Daten schnell herunter.
Wenn es nicht eingehängt wird, prüfe die Systemprotokolle:
log show --last 10m --predicate 'process == ‘diskmanagementd’ || process == ‘apfsd’
Diese Protokolle zeigen oft den wahren Grund. Ich habe dort schon ‘wrong fs type’, ‘invalid spaceman oid’ und Container-Checkpoint-Fehler gesehen.
Wenn das Festplattendienstprogramm fehlschlägt und deine Daten wichtig sind, wechsle zur Wiederherstellung, bevor du löschst. Disk Drill ist einen Versuch wert für die APFS-Datenwiederherstellung, weil es den Datenträger scannt, ohne ein normales Einhängen zu benötigen. Wenn du auch mit älteren Mac-Formaten arbeitest, ist dieser Leitfaden zum Reparieren eines HFS-Katalogs und Beheben von Disenter-Einhängefehlern ebenfalls relevant.
Noch etwas. Teste das Laufwerk an einem anderen Mac und an einem direkten Anschluss, ohne Hub. Ich habe erlebt, dass zwei tote APFS-Laufwerke allein dadurch wieder funktioniert haben.
Ich würde com.apple.diskmanagement.disenter weniger als Der Datenträger ist tot behandeln und eher als macOS ist beim Einhängen auf etwas gestoßen, das ihm nicht gefällt. Manchmal ist das APFS-Beschädigung, manchmal seltsame Berechtigungs-/Verschlüsselungsprobleme, und manchmal lügt das Gehäuse gerade genug, um dir den Nachmittag zu verderben.
Eine Sache, die ich von @mikeappsreviewer oder @hoshikuzu nicht oft genug erwähnt sehe: Prüfe, ob der Datenträger überhaupt sinnvolle SMART- / Bridge-Informationen meldet. Im Terminal:
diskutil info /dev/diskX
system_profiler SPUSBDataType
system_profiler SPThunderboltDataType
Wenn das Gehäuse eine instabile Verbindungsgeschwindigkeit zeigt, die Seriennummer fehlt oder es sich ständig neu verbindet, hör zuerst auf, APFS zu untersuchen. Das Dateisystem könnte einigermaßen in Ordnung sein, die USB-Bridge könnte hier der Clown sein.
Außerdem, wenn es sich um ein externes APFS-verschlüsseltes Volume handelt, versuche es vor dem Einhängen zu entsperren:
diskutil apfs unlockVolume /dev/diskXsY
Ich habe disenter-Fehler gesehen, bei denen das eigentliche Problem war, dass der Entsperrungsschritt stillschweigend fehlschlug.
Wenn deine Daten wichtig sind, führe noch keine zufälligen schreibintensiven Reparaturen aus. Am besten klonst/erstellst du zuerst ein Image des Datenträgers, wenn er instabil ist. Arbeite dann mit dem Klon. Das ist ein langweiliger Rat, aber langweilig ist, wie man Dateien behält. Wenn sich das Volume nicht einhängen lässt und Erste Hilfe nicht weiterkommt, ist Disk Drill eine der praktischeren Optionen für ein nicht einhängbares APFS-Laufwerk, weil es ohne normales Einhängen scannen und dich Dateien wiederherstellen lassen kann, bevor du löschst/neu aufbaust.
Bei der Auswahl von Software würde ich es so formulieren: beste Datenrettungssoftware für ein nicht einhängbares Laufwerk mit APFS-Unterstützung. Wenn du eine grundlegende Anleitung möchtest, ist das hier relevant: wie man Dateien von einem nicht einhängbaren Mac-Laufwerk wiederherstellt.
Noch eine weitere halb-nervige Realität: Wenn das Laufwerk auf einem anderen Mac sofort eingehängt wird, könnte deine aktuelle macOS-Installation das Problem sein, nicht der Datenträger. Schon gesehen. Gehasst.
Ich würde noch einen Aspekt ergänzen, den die Antworten von @hoshikuzu, @espritlibre und @mikeappsreviewer nur indirekt angesprochen haben: APFS-Snapshot- und Seal-Probleme, besonders wenn dies früher eine Systemfestplatte war oder von einer geklont wurde. Ich habe erlebt, dass com.apple.diskmanagement.disenter auftritt, wenn das Volume selbst lesbar ist, macOS aber ein normales Einbinden verweigert, weil der Snapshot-Baum oder die Volume-Rollen-Metadaten inkonsistent sind.
Ein paar Prüfungen, die risikoarm sind und sich vom üblichen Erste-Hilfe-Kreislauf unterscheiden:
tmutil listlocalsnapshots /
diskutil apfs listSnapshots /dev/diskXsY
mount
Wenn das betroffene Volume extern ist und sehr viele Snapshots hat, kann das das Einbinden erschweren. Prüfe auch, ob Finder das Problem ist und nicht das Dateisystem, indem du Folgendes versuchst:
sudo mkdir /Volumes/testmount
sudo mount_apfs -o rdonly /dev/diskXsY /Volumes/testmount
Das umgeht einen Teil des höherstufigen DiskManagement-Verhaltens. Wenn das funktioniert, sind deine Daten wahrscheinlich weniger gefährdet, als es die Fehlermeldung vermuten lässt.
Ein kleiner Widerspruch zur Idee einfach fsck zu beenden: Wenn die Festplatte klickt, die Verbindung verliert oder I/O-Fehler ausgibt, würde ich nichts unterbrechen. Dann sollte man zuerst ein Image erstellen oder stoppen.
Wenn das Laufwerk wichtig ist, prüfe auch rohe Hinweise zum Zustand:
ioreg -p IOUSB -l | grep -i -E 'Product|Vendor|Serial'
log show --last 30m | grep -i 'I/O error'
Wiederholte I/O-Fehler bedeuten normalerweise, dass das Gehäuse oder der Pfad zur Festplatte das eigentliche Problem ist.
Wenn du kein stabiles schreibgeschütztes Einbinden hinbekommst, ist Disk Drill ein vernünftiger nächster Schritt.
Vorteile
- gute APFS-Unterstützung
- kann nicht einbindbare Volumes scannen
- einfacherer Vorschau-/Export-Ablauf als bei vielen anderen Tools
Nachteile
- Tiefenscans können ewig dauern
- Vorschau-Namen/Ordner sind bei beschädigtem APFS nicht immer perfekt
- kostenpflichtige Wiederherstellung, wenn du eine vollständige Extraktion brauchst
Die Ursache fällt also meist in eine von drei Kategorien: Inkonsistenz der APFS-Metadaten, Merkwürdigkeiten bei Verschlüsselung/Snapshots/Rollen oder ein instabiler Hardware-Pfad. Deine Daten sind nicht automatisch verloren, nur weil macOS das Einbinden verweigert. Wenn überhaupt, ist der größte Fehler, zu viele Schreibaktionen zu versuchen, bevor man die Dateien herauskopiert.