Kon Com.apple.diskmanagement.disenter-fout 49223 niet koppelen

Ik probeer een schijf op mijn Mac te koppelen, maar het blijft mislukken met de melding com.apple.diskmanagement.disenter-fout 49223. De schijf wordt weergegeven, maar ik kan niet bij de bestanden en ik maak me zorgen over gegevensverlies. Ik heb hulp nodig om te achterhalen wat deze Mac-schijfkoppelingsfout veroorzaakt en wat de veiligste manier is om dit op te lossen.

Ik liep tegen precies dezelfde puinhoop aan met een grijze schijf in Schijfhulpprogramma en de fijne melding Error 0. Mac ziet het apparaat wel, maar weigert het bestandssysteem te koppelen. Het gebruikelijke label ervoor is com.apple.DiskManagement.disenter. In gewoon Nederlands: de hardware verschijnt, het volume niet.

Wat ik steeds bleef zien, kwam neer op drie dingen. Verkeerd loskoppelen, problemen met een niet-overeenkomend bestandssysteem op Monterey of Ventura, of fsck dat op de achtergrond blijft hangen en nooit klaar komt.

Als je bestanden belangrijk zijn, zou ik stoppen er blind mee te rommelen. Begin eerst met de dingen met het laagste risico.

1. Beëindig het vastgelopen fsck-proces

Dit heeft het bij mij meer dan eens opgelost.

Als de schijf is losgekoppeld zonder deze uit te werpen, start macOS vaak fsck, het controleproces van het bestandssysteem. Terwijl dit draait, blijft de schijf vergrendeld. Op sommige exFAT-schijven en op grotere schijven lijkt het eindeloos te blijven hangen. Ik zag dit op een externe schijf van 5 TB en dacht dat het ding kapot was. Dat was niet zo. Het zat vast.

Open Terminal via Programma's > Hulpprogramma's en voer uit:

sudo pkill -f fsck

Typ je Mac-wachtwoord en druk op Enter. Je ziet het wachtwoord niet terwijl je typt. Nadat ik dit had gedaan, werd de schijf een keer meteen aangekoppeld, en een andere keer duurde het ongeveer 15 seconden. Als deze terugkomt als alleen-lezen, kopieer dan eerst je bestanden eraf. Blijf het noodlot niet tarten.

2. Voer EHBO uit op de juiste onderdelen, in de juiste volgorde

Veel mensen voeren EHBO alleen uit op de volumenaam. Dat deed ik eerst ook. Daardoor werd niet alles gevonden.

Klik in Schijfhulpprogramma op Weergave en vervolgens op Toon alle apparaten. Je wilt de volledige structuur zien, niet de vereenvoudigde weergave. Voer daarna EHBO in deze volgorde uit:

Fysieke schijf
Container, als die bestaat
Volume

Ik had een geval waarbij de eerste poging mislukte, de tweede poging minder klachten gaf en de derde poging het aankoppelingsprobleem uiteindelijk oploste. Voelt stom, maar ik zag hoe het na meerdere keren uitvoeren header- en boomstructuurfouten herstelde.

3. Log uit en daarna weer in

Dit klinkt nep totdat het werkt.

Op Monterey en Ventura zag ik gevallen waarin DiskManagement zich vreemd gedroeg op accountniveau. Uitloggen uit mijn gebruikerssessie en weer inloggen zorgde ervoor dat de schijf werd aangekoppeld. Een tweede gebruikersaccount op dezelfde Mac hielp ook een keer. Als de schijf daar probleemloos opent, heeft je hoofdaccount waarschijnlijk een kapotte voorkeur- of machtigingsstatus. Vervelend, maar nuttig om te weten.

4. Controleer op interferentie van Time Machine

Als de schijf vroeger een Time Machine-doel was, houdt macOS er soms grip op vanwege snapshots of back-upinstellingen.

Ik heb Back-up automatisch maken uitgeschakeld in Systeeminstellingen en daarna de schijf opnieuw aangesloten. Dat was één keer genoeg. Niet elegant. Werkte alsnog.

5. Stop met het forceren van koppelingen als de fouten zich blijven opstapelen

Hier ging het de eerste keer bij mij mis. Ik bleef opdrachten opnieuw proberen, opnieuw koppelen, EHBO, loskoppelen, opnieuw aansluiten. Slecht idee.

Als Terminal-trucjes niet werken en Schijfhulpprogramma fouten blijft geven, laat het bestandssysteem dan even met rust. Herhaalde koppelingspogingen op een beschadigde schijf kunnen het erger maken. Dat heb ik op de harde manier geleerd met een oudere WD-schijf. Hoe meer ik testte, hoe minder leesbaar die werd.

In dat stadium ben ik overgestapt op herstelsoftware. Degene die ik gebruikte was Disk Drill. Wat voor mij belangrijk was, was simpel. Die scande de ruwe schijf zonder dat macOS eerst het volume hoefde te koppelen.

Op mijn WD_Black haalde het de mapstructuur goed genoeg naar voren in de voorbeeldweergave zodat ik werkbestanden en foto's naar een goede schijf kon kopiëren. Ik gaf minder om perfecte recovery en meer om het veiligstellen van de belangrijke bestanden voordat ik opnieuw reparaties probeerde.

6. Alleen opnieuw formatteren nadat je gegevens veilig zijn

Zodra je bestanden zijn gekopieerd, wis je de schijf volledig als je die wilt blijven gebruiken.

Selecteer in Schijfhulpprogramma het fysieke apparaat, niet alleen het volume, en klik dan op Wis.

Gebruik deze indelingen op basis van waar de schijf gebruikt zal worden:

Alleen Mac, APFS of Mac OS Extended (Journaled)
Mac en Windows, exFAT

Ik zou exFAT op de Mac formatteren als de schijf daar voornamelijk wordt gebruikt. Ik had op die manier minder vreemde compatibiliteitsproblemen.

Wat ik in volgorde zou doen

1. Probeer sudo pkill -f fsck
2. Voer EHBO uit met Toon alle apparaten ingeschakeld
3. Meld je af en weer aan, of test een andere gebruikersaccount
4. Schakel automatische Time Machine-back-up uit als dat van toepassing is
5. Herstel bestanden vóór meer reparatiepogingen
6. Wis en formatteer opnieuw na herstel

Nog één ding. Grote schijven duren eeuwig. Bij 4TB en hoger kunnen EHBO- en scantaken daar zo lang blijven staan dat je denkt dat er niets gebeurt. Ik heb er zelf ook bijna eentje te vroeg geannuleerd. Laat het doorlopen.

Fout 49223 betekent meestal dat macOS de hardware ziet, maar het bestandssysteem of de partitietabel afwijst. Ik ben het eens met een deel van wat @mikeappsreviewer zei, maar ik zou niet beginnen met het beëindigen van willekeurige fsck-processen tenzij je al hebt bevestigd dat er één vastzit op je schijf. Als fsck midden in een reparatie zit en je beëindigt het op het verkeerde moment, loop je het risico op een nog grotere puinhoop.

Wat ik eerst zou controleren:

  1. Identificeer de schijf in Terminal.
    Voer uit:
    diskutil list

Zoek de identifier van de externe schijf, zoals disk4 of disk4s1.

  1. Lees de reden van de koppelingsfout.
    Voer uit:
    diskutil mountDisk /dev/disk4

of voor één volume:
diskutil mount /dev/disk4s1

Als het opnieuw mislukt, haal dan de logs op:
log show --last 10m | grep -i disenter

Hieruit blijkt vaak of het probleem exFAT-corruptie, GPT-schade of een geweigerde toestemming is.

  1. Controleer de partitietabel.
    Voer uit:
    diskutil verifyDisk /dev/disk4

Als de partitietabel beschadigd is, zal Eerste hulp op het volume niet veel oplossen. Je moet eerst de bovenliggende schijf controleren.

  1. Probeer een andere kabel, poort of een hub met voeding.
    Dit klinkt saai, maar slechte USB-kabels veroorzaken vaker koppelingsfouten dan mensen toegeven. Ik heb ooit een Samsung T7 gehad die dood leek met de ene USB-C-kabel en prima koppelde met een andere. Dezelfde Mac. Dezelfde schijf. Stom, maar waar.

  2. Test op een tweede machine.
    Als hij op een andere Mac of een Windows-pc koppelt, kopieer de gegevens er dan snel af. Als hij nergens werkt, stop dan met eraan te prutsen.

Als je bestanden belangrijk zijn, schakel dan eerder over van reparatie naar herstel. Disk Drill is een degelijke optie voor Mac wanneer de schijf in Schijfhulpprogramma verschijnt maar weigert te koppelen. Het scant het ruwe apparaat en vindt vaak bestanden, zelfs wanneer Finder niets ziet. Dat is de veiligere stap vóór wispogingen.

Na herstel wis je de fysieke schijf, bouw je de partitietabel opnieuw op en formatteer je hem daarna opnieuw. Voor een duidelijke uitleg over wanneer formatteren dit soort problemen oploste, zie formatteren loste de disenter-fout op Mac op.

Als je de uitvoer van diskutil list en verifyDisk plaatst, kunnen mensen hier je vertellen of dit bestandssysteembeschadiging is of dat de hardware het aan het begeven is.

Fout 49223 is een van die irritant vage macOS-fouten waarbij de schijf wel wordt gezien maar het volume niet netjes wordt gekoppeld. @mikeappsreviewer en @vrijheidsvogel hebben de gebruikelijke reparatiehoek al behandeld, dus ik zou hier iets anders naar kijken: uitzoeken of het probleem bij het bestandssysteem, de behuizing of de gezondheid van de schijf ligt voordat je mounts blijft proberen.

Een paar dingen die ik zou doen en die eigenlijk niet genoeg zijn benadrukt:

1. Controleer SMART / hardwaregezondheid
In Terminal:

diskutil info /dev/diskX

Zoek naar de SMART-status als die beschikbaar is. Als de behuizing SMART verbergt, probeer dan een andere behuizing of adapter. Een defecte USB-SATA-bridge kan mountfouten veroorzaken die op beschadiging van het bestandssysteem lijken.

2. Kijk of de schijf door de kernel alleen-lezen wordt gekoppeld
Voer uit:

mount

en

diskutil info /dev/diskXs1

Soms is de schijf technisch gezien in een beperkte toestand gekoppeld en doet Finder gewoon nutteloos.

3. Als het een externe HDD is, luister ernaar
Klikgeluiden, spin-up/spin-down-lussen of lange pauzes zijn slechte signalen. Als dat gebeurt, stop dan met steeds opnieuw EHBO uitvoeren. Dat voegt alleen maar extra belasting toe.

4. Maak eerst een kloon als de gegevens belangrijk zijn
Hier ben ik het soort van oneens met de mentaliteit van blijven reparaties proberen. Als de schijf instabiel lijkt, maak dan indien mogelijk eerst een sector-voor-sector-kopie en werk daarna met de kopie. Als je hem niet kunt koppelen maar het apparaat nog wel verschijnt, is Disk Drill een praktische optie omdat het de ruwe schijf kan scannen en bestanden kan herstellen zonder dat Finder hoeft mee te werken.

5. Controleer Apple silicon / vreemde stroomproblemen
Bij sommige schijven die via de bus worden gevoed, veroorzaakt te weinig stroom vanaf een poort willekeurige disenter-fouten. Probeer een directe verbinding, geen goedkope hub, of gebruik een hub met voeding. Klinkt dom, lost veel te vaak dingen op.

Dit was trouwens ook een aardige uitleg van iemand die met een vergelijkbare Mac-schijfkoppelingschaos te maken had: hoe een Mac-gebruiker de DiskManagement disenter-koppelfout heeft opgelost

Als de schijf zichtbaar is maar nergens wil koppelen, zou ik stoppen met reparaties najagen en meteen overstappen op herstel, en pas daarna opnieuw formatteren. Als je diskutil list en diskutil info plaatst, kunnen mensen waarschijnlijk vrij snel zien of dit beschadiging is of dat de schijf begint te overlijden.

Eén invalshoek ontbreekt nog van @vrijheidsvogel, @sonhadordobosque en @mikeappsreviewer: controleer of het volume simpelweg is gemarkeerd als inactief / verborgen / niet doorbladerbaar, vooral als het voor het laatst is aangeraakt door Windows, Linux of partitietools.

In Terminal:

diskutil apfs list
diskutil list
sudo gpt -r show /dev/diskX
sudo fdisk /dev/diskX

Waarom? Fout 49223 kan optreden zelfs wanneer het bestandssysteem grotendeels in orde is, maar de partitiemetadata vreemd genoeg zijn waardoor macOS weigert het normaal te koppelen.

Ook de moeite waard om te controleren of macOS het weigert vanwege eigendom / verouderde aankoppelpunt-rommel:

ls -la /Volumes

Als je een achtergebleven map ziet met dezelfde volumenaam, hernoem of verwijder dan dat lege aankoppelpunt en probeer het opnieuw.

Met één ding ben ik het enigszins oneens: ik zou Eerste hulp niet te vaak opnieuw blijven uitvoeren op een twijfelachtige HDD. Verificatie is goedkoop. Herhaald repareren is dat niet.

Als de schijf zichtbaar is maar kostbaar, zou ik eerder neigen naar Disk Drill vóór meer reparatiepogingen.

Voordelen van Disk Drill

  • scant niet-aangekoppelde volumes
  • goede ondersteuning voor voorvertoning
  • eenvoudig voor gebruikers die de terminal niet gebruiken

Nadelen

  • geen wondermiddel bij falende hardware
  • diepe scans kunnen eeuwig duren
  • herstelkwaliteit hangt af van schade aan het bestandssysteem

Als Disk Drill je bestanden vindt, kopieer ze dan eerst weg en bouw de schijf daarna volledig opnieuw op. Als het niets vindt en de schijf geluid maakt of de verbinding verbreekt, verschuif je van een softwareprobleem naar een hardwareprobleem.