Mijn APFS-schijf stopte plotseling met koppelen op mijn Mac en ik blijf de fout com.apple.diskmanagement.disenter krijgen. Ik heb hulp nodig om uit te zoeken waardoor dit is veroorzaakt, of mijn gegevens gevaar lopen en welke stappen ik kan nemen om de schijf veilig te koppelen zonder het probleem erger te maken.
Ik liep tegen dezelfde rommel met de disenter-fout aan op macOS, en het voelde minder als een schijffout en meer alsof macOS de koppeling op systeemniveau weigerde. De Mac zag de hardware. De bestandssysteemservice maakte de taak niet af, waardoor de schijf daar nutteloos bleef staan.
Wat er bij mij steeds gebeurde
Wat ik het vaakst zag, was dat fsck op de achtergrond vastliep. Als je een schijf loskoppelt zonder die eerst uit te werpen, start macOS meestal de volgende keer dat je die aansluit een controle van het bestandssysteem. Op papier prima. In de praktijk heb ik het eindeloos zien vastlopen op grote ExFAT-schijven en grotere APFS-volumes. Terwijl het vastzit, blijft de schijf vergrendeld en wordt die niet gekoppeld.
De Terminal-oplossing die ik eerst probeerde
Open Terminal en voer uit:
sudo pkill -f fsck
Je hebt je beheerderswachtwoord nodig. Nadat ik dit deed, werd de schijf meteen meer dan eens gekoppeld. Een paar keer kwam hij terug als alleen-lezen, wat voor mij prima was, omdat ik alleen bestanden eraf hoefde te halen voordat ik iets anders deed.
Schijfhulpprogramma, maar in de juiste volgorde
Dit onderdeel wordt vaak overgeslagen. Klik niet alleen op EHBO bij het gedimde volume en noem het dan klaar.
In Schijfhulpprogramma:
Weergave > Toon alle apparaten
Voer daarna EHBO uit in deze volgorde:
1. De fysieke schijf
2. De container
3. Het volume
Ik had een geval waarbij de eerste keer mislukte, de tweede keer een klacht gaf over de map en de derde keer het eindelijk oploste. Dus als er één keer een fout optreedt, zou ik daar niet stoppen. Een herhaalde poging verandert soms het resultaat.
Wanneer EHBO het opgeeft
Als Schijfhulpprogramma afsluitcode 8 geeft, of zegt dat het volume niet kan worden hersteld, zou ik stoppen met erop te blijven hameren. Ik heb dit op de harde manier geleerd. Herhaalde koppelingspogingen op een beschadigd bestandssysteem zijn een slechte gok als de gegevens belangrijk zijn.
Op dat moment zou ik overschakelen op herstel voordat ik iets destructiefs doe. Disk Drill hielp in een geval waarin macOS weigerde de schijf überhaupt te koppelen. Het scande de ruwe sectoren en liet genoeg van de mapstructuur zien zodat ik eerst bestanden naar een andere schijf kon kopiëren. Dat was het deel waar ik om gaf. Sla de gegevens op, wis later.
Een vreemd macOS-gedrag
Ik zag ook een vreemde oplossing aan de systeemkant op nieuwere macOS-versies. Uitloggen van je account en opnieuw inloggen zorgde er soms voor dat het vastgelopen DiskManagement-proces werd gereset. Opstarten in Veilige modus deed op mijn machine een keer hetzelfde. Als je bijna van plan bent te herformatteren, zou ik deze opties eerst proberen, omdat ze minder tijd kosten en je bestanden niet aanraken.
Als de fout com.apple.diskmanagement.disenter is, zou ik eerst naar drie oorzaken kijken.
- APFS-metadataschade. De superblock van de container of het volume raakt beschadigd na een slechte ontkoppeling, crash of stroomuitval.
- macOS-beleid blokkeert de koppeling. Ik heb dit gezien na OS-updates, vooral wanneer de schijf versleuteld was of van een andere Mac was.
- Problemen in het hardwarepad. Slechte USB-C-hubs, zwakke kabels en behuizingen veroorzaken gedeeltelijke leesacties. De schijf verschijnt, maar koppelen mislukt.
Ik ben het op één punt licht oneens met @mikeappsreviewer. fsck beëindigen helpt in sommige gevallen, maar als je APFS-metadata al instabiel is, is dingen forceren tijdens een controle riskant. Als de bestanden belangrijk zijn, begin dan met inspectie, niet met forceren.
Wat ik zou doen:
Voer uit:
diskutil list
Zoek de APFS-container- en volume-ID’s. Voer daarna uit:
diskutil apfs list
Zoek naar:
- FileVault-vergrendelingsstatus
- Fusion-mismatch
- Fouten in Physical Store
- Vreemd snapshot-gedrag
- Role-mismatch op het volume
Probeer daarna een handmatige koppeling in Terminal:
sudo diskutil mount readOnly /dev/diskXsY
Alleen-lezen is eerst veiliger. Als het koppelt, kopieer de gegevens er dan snel af.
Als het niet koppelt, controleer dan de systeemlogboeken:
log show --last 10m --predicate 'process == ‘diskmanagementd’ || process == ‘apfsd’
Die logboeken tonen vaak de echte reden. Ik heb daar ‘wrong fs type’, ‘invalid spaceman oid’ en container-checkpointfouten gezien.
Als Schijfhulpprogramma faalt en je gegevens belangrijk zijn, schakel dan over op herstel voordat je wist. Disk Drill is het proberen waard voor APFS-gegevensherstel, omdat het de schijf scant zonder een normale koppeling nodig te hebben. Als je ook met oudere Mac-indelingen werkt, is deze gids over het herstellen van een HFS-catalogus en het oplossen van disenter-koppelingsfouten ook relevant.
Laatste ding. Test de schijf op een andere Mac en op een directe poort, zonder hub. Ik heb twee dode APFS-schijven zien terugkomen door alleen dat te doen.
Ik zou com.apple.diskmanagement.disenter minder behandelen als de drive is dood en meer als macOS iets tegenkwam wat het niet prettig vindt tijdens het koppelen. Soms is dat APFS-corruptie, soms rare toestemmings-/versleutelingsproblemen, en soms liegt de behuizing net genoeg om je middag te verpesten.
Iets wat ik @mikeappsreviewer of @hoshikuzu niet vaak genoeg genoemd zie worden: controleer of de schijf überhaupt normale SMART- / bridge-info rapporteert. In Terminal:
diskutil info /dev/diskX
system_profiler SPUSBDataType
system_profiler SPThunderboltDataType
Als de behuizing een instabiele linksnelheid toont, een ontbrekend serienummer heeft, of steeds opnieuw verbinding maakt, stop dan eerst met het troubleshooten van APFS. Het bestandssysteem kan min of meer in orde zijn, de USB-bridge kan hier de clown zijn.
Als dit ook nog een externe versleutelde APFS-volume is, probeer dan eerst te ontgrendelen voordat je koppelt:
diskutil apfs unlockVolume /dev/diskXsY
Ik heb disenter-fouten gezien waarbij het echte probleem was dat de ontgrendelingsstap stilletjes mislukte.
Als je gegevens belangrijk zijn, voer dan nog geen willekeurige schrijfintensieve fixes uit. De beste zet is om de schijf eerst te klonen/imagingen als die instabiel is. Werk daarna vanaf de kloon. Dat is saai advies, maar saai is hoe je bestanden bewaart. Als het volume niet wil koppelen en Schijf-EHBO nergens toe leidt, is Disk Drill een van de praktischere opties voor een niet-koppelbare APFS-drive, omdat het kan scannen zonder normale koppeling en je bestanden laat herstellen vóór wissen/heropbouwen.
Voor het kiezen van software zou ik het zo formuleren: beste dataherstelsoftware voor een niet-koppelbare drive met APFS-ondersteuning. Als je een basisuitleg wilt, is dit relevant: hoe je bestanden herstelt van een niet-koppelbare Mac-drive.
Nog een half irritante realiteit: als de drive op een andere Mac direct koppelt, kan je huidige macOS-installatie het probleem zijn, niet de schijf. Gezien. Gehaat.
Ik zou nog één invalshoek toevoegen die in de reacties van @hoshikuzu, @espritlibre en @mikeappsreviewer alleen zijdelings aan bod kwam: problemen met APFS-snapshots en seals, vooral als dit vroeger een systeemschijf was of daarvan is gekloond. Ik heb com.apple.diskmanagement.disenter zien optreden wanneer het volume zelf leesbaar is, maar macOS een normale koppeling weigert omdat de snapshot-boom of de metagegevens van de volumenrol inconsistent zijn.
Een paar controles met laag risico die anders zijn dan de gebruikelijke First Aid-lus:
tmutil listlocalsnapshots /
diskutil apfs listSnapshots /dev/diskXsY
mount
Als het getroffen volume extern is en heel veel snapshots heeft, kan dat het koppelen bemoeilijken. Controleer ook of Finder het probleem is en niet het bestandssysteem door dit te proberen:
sudo mkdir /Volumes/testmount
sudo mount_apfs -o rdonly /dev/diskXsY /Volumes/testmount
Dat omzeilt een deel van het DiskManagement-gedrag op hoger niveau. Als dit werkt, lopen je gegevens waarschijnlijk minder risico dan de foutmelding doet vermoeden.
Een klein meningsverschil met het idee om fsck gewoon te stoppen: als de schijf klikkende geluiden maakt, de verbinding verbreekt of I/O-fouten geeft, zou ik niets onderbreken. Dan maak je eerst een image of stop je.
Als de schijf belangrijk is, controleer dan ook ruwe aanwijzingen over de gezondheid:
ioreg -p IOUSB -l | grep -i -E 'Product|Vendor|Serial'
log show --last 30m | grep -i 'I/O error'
Herhaalde I/O-fouten betekenen meestal dat de behuizing of het schijfpad het echte probleem is.
Als je geen stabiele alleen-lezen-koppeling kunt krijgen, is Disk Drill een redelijke volgende stap.
Voordelen
- goede APFS-ondersteuning
- kan niet-aangekoppelde volumes scannen
- eenvoudigere preview/exportworkflow dan veel andere tools
Nadelen
- diepe scans kunnen eindeloos duren
- namen/mappen in de preview zijn niet altijd perfect op beschadigde APFS
- betaalde recovery als je volledige extractie nodig hebt
Dus de oorzaak valt meestal in een van drie categorieën: inconsistentie in APFS-metagegevens, eigenaardigheden met encryptie/snapshots/rollen, of een haperend hardwarepad. Je gegevens zijn niet automatisch weg alleen omdat macOS de koppeling weigert. Als er al een grote fout wordt gemaakt, is het te veel schrijfacties proberen voordat bestanden eruit zijn gekopieerd.