Mijn externe HDD werkte prima, maar wilde toen plotseling niet meer koppelen op mijn Mac en geeft nu een com.apple.diskmanagement.disenter-fout weer. Ik heb hulp nodig om uit te zoeken waardoor dit is veroorzaakt en hoe ik weer veilig toegang kan krijgen tot mijn bestanden zonder de schijf verder te beschadigen.
Ik ben dit een tijdje terug ook tegengekomen met een externe SSD. Schijfhulpprogramma zag de schijf wel, maar die bleef grijs en gaf de fout com.apple.DiskManagement.disenter. Voor zover ik kon zien, wist macOS dat de hardware er was, maar iets blokkeerde dat het bestandssysteem werd aangekoppeld.
Wat het bij mij veroorzaakte, was een van de gebruikelijke rotzooi-oorzaken. De schijf was losgekoppeld zonder uit te werpen, het bestandssysteem had schade opgelopen, of macOS had een vastgelopen schijfcontrole op de achtergrond die het volume gegijzeld hield.
Dit is de volgorde die ik heb doorlopen, en dat heeft me wat tijd bespaard.
Begin met de vastgelopen hersteltaak
Als de schijf op de verkeerde manier is losgekoppeld, start macOS vaak fsck op de achtergrond. Dat is de ingebouwde controle van het bestandssysteem. In theorie prima. Vervelend als die vastloopt, want dan blijft de schijf onaangekoppeld staan en wacht je voor niets.
Open Terminal en voer uit:
sudo pkill -f fsck
Druk op Enter, typ je wachtwoord, en maak je geen zorgen als je geen tekens ziet tijdens het typen. Dat doet macOS nu eenmaal.
Als de schijf hierna verschijnt, stop dan meteen met eraan rommelen en kopieer je bestanden er direct af. Echt waar. Als die alleen-lezen wordt aangekoppeld, is dat alleen maar meer reden om snel te handelen.
Voer EHBO uit op de hele keten
Schijfhulpprogramma verbergt standaard dingen, wat irritant is. Open het, klik op Weergave en kies dan Toon alle apparaten.
Begin daarna niet met het volume. Werk van boven naar beneden.
- Voer EHBO uit op de fysieke schijf.
- Voer het daarna uit op de container, als die zichtbaar is.
- Voer het daarna uit op het volume.
Ik had meer succes met deze volgorde omdat het zichtbare volume niet altijd de echte bron van de fout was. Soms zat de rommel een niveau hoger. Ik heb EHBO ook meer dan eens opnieuw uitgevoerd. Het voelt dom, maar ik heb herhaalde pogingen wel header- of mapstructuurproblemen zien oplossen wanneer de eerste uitvoering niet netjes werd afgerond.
Probeer een schone gebruikerssessie
Een keer was de schijf niet het hoofdprobleem. Mijn inlogsessie was dat. Ik meldde me af, meldde me weer aan, en de schijf werd aangekoppeld. Op een andere Mac testte ik met een tweede gebruikersaccount en kreeg ik hetzelfde soort resultaat.
Dus meld je af van je account en weer aan. Als je nog een andere gebruiker op dezelfde Mac hebt, test daar ook. Als de schijf in het andere account wel wordt aangekoppeld, zit je normale profiel waarschijnlijk vast op machtigingen, voorkeuren of een of andere sessiefout.
Controleer Time Machine
Deze verraste me. Als de schijf vroeger een Time Machine-doel was, blijft macOS er soms op de achtergrond aan zitten peuteren.
Ga naar Systeeminstellingen, schakel automatische Time Machine-reservekopieën voorlopig uit en probeer de schijf daarna opnieuw aan te koppelen. Ik zou deze stap niet overslaan als de schijf enige back-upgeschiedenis heeft.
Als die nog steeds weigert aan te koppelen
Op een gegeven moment is repareren niet meer slim maar riskant. Als de schijf fouten blijft geven, zou ik overschakelen van de modus herstellen naar de modus gegevens eruit halen.
Ik heb voor dit soort gevallen tools gebruikt zoals Disk Drill. Het punt is niet om te wachten tot macOS het bestandssysteem normaal aankoppelt. Het scant een lager niveau en haalt soms bestanden op of bouwt een bruikbaar overzicht van mappen opnieuw op, zelfs wanneer Finder je niets geeft.
Belangrijk punt: herstel naar een andere gezonde schijf. Schrijf herstelde bestanden niet terug naar dezelfde falende schijf. Zo maken mensen een slechte dag nog erger. Vraag me maar hoe ik dat weet, haha.
Wis de schijf nadat je bestanden veilig zijn
Zodra je belangrijke spullen ergens anders naartoe zijn gekopieerd, wis je de probleemschijf en stel je die opnieuw in via Schijfhulpprogramma.
Kies de fysieke schijf, klik op Wis en kies dan de structuur op basis van waar je die gebruikt:
- APFS voor modern gebruik met alleen Mac.
- Mac OS Uitgebreid Journaled voor oudere Mac-configuraties.
- exFAT als de schijf tussen macOS en Windows moet worden gebruikt.
Als de schijf voornamelijk op je Mac wordt gebruikt, werkte formatteren op de Mac voor mij beter.
De korte versie
Raak niet in paniek. Blijf niet een uur lang steeds opnieuw EHBO uitvoeren terwijl de schijf verder achteruitgaat. Als die wordt aangekoppeld, kopieer dan eerst. Als dat niet lukt, ga dan richting herstel. Zodra je gegevens veilig zijn, wis en formatteer je de schijf opnieuw.
En ja, werp externe schijven altijd uit voordat je ze loskoppelt. Ik was één keer lui. De schijf liet me daarvoor betalen.
Als de schijf verschijnt in Schijfhulpprogramma maar com.apple.diskmanagement.disenter geeft, zou ik eerst naar de verbindingslaag kijken, niet eerst naar fsck zoals @mikeappsreviewer deed.
Een paar oorzaken die ik heb gezien:
- Slechte USB-kabel of zwakke voeding van de USB-hub.
- Defecte SATA-bridge in de externe behuizing.
- Bestandssysteem komt niet overeen of beschadigde partitietabel.
- macOS blokkeert het koppelen omdat de schijf slechte sectoren rapporteert.
Doe dit in deze volgorde.
-
Sluit hem direct aan op de Mac.
Geen hub. Geen dock. Geen keten van adapters als je dat kunt vermijden. -
Verwissel de kabel.
Dit verhelpt meer dode schijven dan mensen toegeven. -
Test een andere poort, daarna een andere Mac.
Als een tweede Mac dezelfde disenter-fout ziet, zit het probleem aan de kant van de schijf. -
Open Terminal en voer uit:
diskutil list
Kijk of de identifiers van de schijf en het volume verschijnen. Voer daarna uit:
diskutil info /dev/diskX
Vervang X door het nummer van je schijf. Controleer op:
SMART-status, als die zichtbaar is.
Bestandssysteemtype.
Alleen-lezenstatus.
Type partitietabel.
- Probeer handmatig te koppelen:
diskutil mountDisk /dev/diskX
of
diskutil mount /dev/diskXsY
Als het mislukt, geeft macOS vaak een nuttigere foutmelding dan Schijfhulpprogramma.
- Controleer systeemlogboeken:
log show --last 10m | grep -i diskmanagement
Dit wijst soms op I/O-fouten, mediadefecten of partitieproblemen.
Als de behuizing het probleem is, haal de HDD eruit en sluit hem aan met een andere SATA-naar-USB-adapter of behuizing. Ik heb meegemaakt dat de printplaat van de behuizing defect raakte terwijl de schijf zelf nog in orde was. Vervelend, maar gebruikelijk.
Als je hoofddoel is om eerst de bestanden veilig te stellen, stop dan na een paar pogingen met willekeurige reparatieschrijfacties. Scan de schijf met Disk Drill en herstel naar een andere schijf. Dat is de veiligere route als de koppelingsfout blijft terugkomen. Als je eerst meer feedback van kopers wilt, lees dan gebruikersreviews en beoordelingen van Disk Drill.
Nog iets dat mensen vaak missen. Als de schijf opstart, klikt, weer stopt met draaien of heel lang nodig heeft om te verschijnen, wijst dat meer op hardware dan op macOS. Op dat punt is elke extra poging om te koppelen een risico.
Ik zou één ding toevoegen waar noch @mikeappsreviewer noch @andarilhonoturno echt genoeg nadruk op legden: controleer of de schijf wel wordt aangekoppeld maar door Finder verborgen wordt, in plaats van echt te falen. Klinkt dom, maar ik heb externe HDD’s de disenter-fout zien geven en daarna toch onder /Volumes of in diskutil zien verschijnen als alleen-lezen aangekoppeld.
Probeer dit in Terminal:
ls /Volumes
mount
diskutil apfs list
Als je daar de volumenaam ziet, kan Finder hier de leugenaar zijn, niet de schijf.
Haast je ook niet met wissen/herformatteren tenzij de gegevens al veilig zijn. Mensen doen dat veel te snel en doen dan verbaasd als de bestanden weg zijn. Als er belangrijke dingen op de schijf staan, maak dan eerst een kloon op byte-niveau als deze überhaupt nog leesbaar is:
sudo dd if=/dev/diskX of=/path/to/healthy/drive/image.dmg bs=4m
Traag? Ja. Saai? Ook ja. Maar veiliger dan eindeloos opnieuw op een stervende schijf prikken.
Nog een invalshoek: als dit direct na een macOS-update begon, controleer dan of het bestandssysteem er een is die je huidige OS volledig ondersteunt. Oudere HFS±schijven, vreemde exFAT-indelingen of NTFS-tools van derden kunnen vreemd aankoppelgedrag veroorzaken. Ik heb Paragon en oude NTFS-stuurprogramma’s complete chaos zien veroorzaken. Verwijder of schakel die uit als ze geïnstalleerd zijn.
Als Schijfhulpprogramma en handmatig aankoppelen allebei mislukken, en de schijf vreemde geluiden maakt of eeuwig nodig heeft om herkend te worden, dan kan het probleem fysieke schijfhardware-uitval zijn in plaats van alleen een macOS-aankoppelfout. Stop op dat punt met hem kapot te testen.
Voor bestandstoegang zonder de situatie erger te maken, is Disk Drill een prima volgende stap. Het is een van de betere Mac-opties voor gegevensherstel voor externe harde schijven die niet aankoppelen, vooral wanneer Finder nutteloos is maar het apparaat nog wel op apparaatsniveau verschijnt.
Als je nog een andere kijk wilt op symptomen van falende externe schijven, is dit het snel doornemen waard:
externe harde schijf wordt niet weergegeven en wat dat meestal betekent
Korte versie: controleer of hij echt niet is aangekoppeld, vermijd schrijfbewerkingen, kloon indien mogelijk en herstel daarna bestanden voordat je fixes probeert. Die volgorde is belangrijk. Heel erg belangrijk.
Eén invalshoek ontbreekt bij @andarilhonoturno, @suenodelbosque en @mikeappsreviewer: controleer of de schijf de privacy- en eigendomslogica van macOS activeert, en niet alleen elektrisch of structureel faalt.
Controleer in Terminal de ruwe reden van de weigerde koppeling:
diskutil unmountDisk force /dev/diskX
sudo mkdir /tmp/testmount
sudo mount -t auto /dev/diskXsY /tmp/testmount
echo $?
Als dat Operation not permitted of eigendomsgerelateerde fouten geeft, controleer dan ook:
sudo diskutil enableOwnership /dev/diskXsY
Een andere nuttige controle is I/O-spam op kernelniveau:
log stream --predicate 'eventMessage contains[c] 'I/O' or eventMessage contains[c] 'disk' --info
Ik ben het eigenlijk niet helemaal eens met de aanpak blijf Eerste hulp proberen. Herhaalde reparatiepogingen op een haperende HDD kunnen de paar goede leesacties die je nog over hebt verspillen. Als SMART slecht is, de schijf traag wordt gedetecteerd, of Console I/O-fouten toont, verander dan meteen van prioriteit: eerst klonen of herstellen.
Als de schijf eerder versleuteld was, test dan of FileVault of APFS-versleutelingsmetadata de echte blokkade vormt:
diskutil apfs list
Soms is de container in orde, maar wordt het volume niet automatisch ontgrendeld.
Voor herstel is Disk Drill een redelijke keuze als de schijf nog steeds wordt gedetecteerd. Voordelen: eenvoudige scanworkflow, goed voor het vinden van bestanden wanneer Finder nutteloos is, degelijke ondersteuning voor voorvertoning. Nadelen: geen wondermiddel bij mechanisch falende schijven, scantijden kunnen lang zijn, en de herstelkwaliteit hangt nog steeds af van hoe leesbaar de schijf is.
Mijn volgorde zou dus zijn: controleer randgevallen rond rechten en versleuteling, bekijk live logs, vermijd herhaalde reparaties op een klikkende of trage HDD, en gebruik daarna Disk Drill of een kloonworkflow vóór enige wisactie.