Ik krijg de fout com.apple.diskmanagement.disenter -119930868 op mijn Mac wanneer ik een externe schijf probeer te koppelen of te openen. Het werkte eerst, maar nu kan Schijfhulpprogramma de schijf niet openen en ik ben bang dat ik mijn bestanden kwijtraak. Ik heb hulp nodig om uit te zoeken waardoor dit is veroorzaakt en hoe ik het veilig kan oplossen.
‘disenter-fout’ op macOS, wat voor mij werkte
Ik liep hiertegenaan met een externe schijf en het was de gebruikelijke macOS-chaos. De Mac zag de hardware, maar het volume kon niet worden aangekoppeld. Simpel gezegd: het systeem zag de schijf, maar Schijfbeheer weigerde het werk af te maken.
Wat ik steeds bleef zien, was een vastgelopen fsck-proces. macOS start dat nadat een schijf op de verkeerde manier is losgekoppeld, of na een rommelige onderbreking van de verbinding. Bij grotere schijven, vooral ExFAT en sommige APFS-volumes, loopt het soms vast en houdt het de schijf eindeloos bezet. De schijf verschijnt wel, maar je kunt hem nog steeds niet openen.
Het eerste dat ik probeerde
Open Terminal en voer uit:
sudo pkill -f fsck
Je hebt je beheerderswachtwoord nodig.
Wat dit voor mij deed, was het bestandssysteemcontroleproces stoppen. Een paar keer werd de schijf direct daarna aangekoppeld. Eén keer kwam hij terug als alleen-lezen, wat prima was. Ik wilde alleen mijn bestanden eraf halen.
Schijfhulpprogramma, maar doe het in de juiste volgorde
Veel mensen klikken alleen op EHBO bij het grijs weergegeven volume en vragen zich dan af waarom er niets verandert. Die fout maakte ik ook.
Dit is de betere volgorde:
- Open Schijfhulpprogramma.
- Klik op Weergave.
- Kies Toon alle apparaten.
- Voer eerst EHBO uit op de bovenste fysieke schijf.
- Voer het daarna uit op de container.
- Voer het daarna uit op het volume zelf.
Als het één keer mislukt, zou ik het nog steeds opnieuw proberen. Ik had één schijf waarbij fouten pas na de derde keer verdwenen. Eerst leek hij dood, daarna kwam EHBO eindelijk door wat er kapot was in de partitie-indeling.
Wanneer EHBO het opgeeft
Als Schijfhulpprogramma exitcode 8 geeft, of zegt dat het volume niet kan worden hersteld, zou ik niet verder aandringen. Herhaalde aankoppelpogingen op een beschadigde schijf zijn geen leuke gok als je gegevens belangrijk zijn.
Op dat punt is de veiligere zet: eerst herstel, daarna reparatie.
Ik gebruikte in één geval Disk Drill omdat macOS het volume helemaal niet wilde aankoppelen. Het kon de schijf nog steeds direct scannen en de bestandsstructuur ophalen. Daardoor kon ik gegevens naar een andere schijf kopiëren voordat ik de defecte schijf wist. Als de catalogus of de index van het bestandssysteem beschadigd is, kunnen dit soort tools soms de ruwe sectoren nog goed genoeg lezen om bestanden te redden.
Eén domme macOS-bug die het proberen waard is
Ik zag ook een vreemd geval waarbij niets het aankoppelprobleem oploste totdat ik uitlogde en weer inlogde. Veilige modus hielp ook een keer. Mijn gok is dat de DiskManagement-service was vastgelopen en dat het herstarten van de gebruikerssessie dat oploste.
Dus voordat je iets wist, zou ik dit proberen:
- uitloggen uit je account en daarna weer inloggen
- opstarten in Veilige modus
- een normale herstart uitvoeren
Het klinkt te simpel, ik weet het. Toch werkte het één keer voor mij, dus ik houd het op de lijst.
Wat ik in deze volgorde zou doen
- Voer
sudo pkill -f fsckuit - Controleer of de schijf wordt aangekoppeld, al is het alleen-lezen
- Schakel in Schijfhulpprogramma Toon alle apparaten in
- Voer EHBO uit van fysieke schijf naar volume
- Als EHBO exitcode 8 meldt of niet wil repareren, stop dan
- Herstel bestanden naar een andere schijf
- Formatteer pas daarna de probleemschijf opnieuw
Fout -119930868 betekent meestal dat macOS de schijf ziet, maar de koppeling weigert omdat het bestandssysteem, de partitietabel of de handshake van de behuizing er verkeerd uitziet. Meestal is dit een van deze dingen:
- Slechte USB-kabel, hub of adapter.
- Beschadigde ExFAT-, APFS- of HFS±metadata.
- NTFS-schijf met onstabiele NTFS-software van derden.
- Stroomprobleem bij grotere externe schijven.
- Defecte bridgeprintplaat van de schijf, zelfs als de schijf zelf nog in orde is.
Ik ben het op één punt een beetje oneens met @mikeappsreviewer. fsck stoppen is prima als het duidelijk is vastgelopen, maar ik zou daar niet mee beginnen als je bestanden belangrijk zijn. Als de schijf klikgeluiden maakt, verdwijnt uit Systeeminformatie of minuten nodig heeft om herkend te worden, zou ik eerst stoppen met koppelpogingen en de hardware controleren.
Wat ik hierna zou doen:
- Probeer een andere kabel en poort, zonder hub.
- Test op een andere Mac. Als het daar ook mislukt, zit het probleem aan de kant van de schijf.
- Open Systeeminformatie, het gedeelte USB of Thunderbolt, en controleer of de behuizing verschijnt.
- Voer in Terminal diskutil list uit. Als de fysieke schijf verschijnt maar het volumetype leeg of vreemd lijkt, is de header van het bestandssysteem beschadigd.
- Als het NTFS is, verwijder dan een oude NTFS-hulpapp. Die veroorzaken vaak disenter-fouten.
- Als Schijfhulpprogramma het nog steeds weigert, schakel dan eerst over naar herstelmodus.
Voor de veiligheid van je gegevens is Disk Drill een solide optie omdat het schijven scant, zelfs wanneer Finder en Schijfhulpprogramma ze niet willen koppelen. Als je doel is om bestanden te redden vóór reparatie, dan zou ik die route nemen.
Als dit ook nog een HFS±schijf is, is een duidelijker herstelpad: gegevens herstellen en de HFS-catalogus opnieuw opbouwen met Disk Drill om de disenter-koppelfout op te lossen. Als je een visuele uitleg wilt, behandelt deze video over het oplossen van de disenter-koppelfout en het opnieuw opbouwen van de HFS-catalogus het proces goed.
Als de schijf ergens alleen-lezen wordt gekoppeld, kopieer je spullen er dan snel vanaf. Blijf hem niet voor de lol testen. Zo maken mensen van een herstelbare schijf een dode schijf.
Die fout betekent meestal dat macOS het apparaat wel kan zien, maar iets aan de volumestructuur niet goed genoeg vindt om het te koppelen. Dus dit is niet altijd dood station = directe ondergang. Soms is het de partitietabel, soms de behuizing, soms is de header van het bestandssysteem gewoon kapot.
Ik ben het grotendeels eens met @mikeappsreviewer en @jeff, maar ik zou niet te lang willekeurige koppel-/reparatiecycli proberen als de bestanden belangrijk zijn. Dat kan snel verkeerd aflopen.
Een paar dingen die ik zou controleren en waar zij niet echt op ingingen:
- Kijk of de schijf op een ander besturingssysteem wordt gekoppeld. Als je toegang hebt tot een Windows-pc en de schijf ExFAT/NTFS is, test daar dan. Als hij opent, stop dan met troubleshooten op de Mac en kopieer eerst de gegevens eraf.
- Controleer de SMART-status als de behuizing dat toelaat. Apps zoals DriveDx of
smartctlkunnen soms aangeven of de schijf fysiek defect raakt. Als SMART er slecht uitziet, blijf er dan niet aan prutsen. - Probeer de losse schijf als die in een verwijderbare behuizing zit. Ik heb meegemaakt dat de USB-SATA-bridge defect was terwijl de schijf zelf prima was. Ontzettend irritant, maar gebruikelijk.
- Koppel eerst elke andere externe schijf los. Klinkt stom, maar ik heb gezien dat Schijfhulpprogramma raar gaat doen wanneer er meerdere haperende externe schijven zijn aangesloten.
Als de schijf niet wil koppelen maar nog wel verschijnt in diskutil list, is dat meestal het moment waarop ik van repareren naar herstellen overstap. Daarvoor is Disk Drill een van de praktischere Mac-opties, omdat het rechtstreeks een niet-koppelbare externe schijf kan scannen en je bestanden kan laten herstellen voordat je opnieuw formatteert. Dat is de veiligere keuze als je je zorgen maakt over gegevensverlies.
Voor iedereen die specifiek naar tools zoekt: dit is het basisidee: beste dataherstelsoftware voor een niet-koppelbare externe schijf op Mac. Ook deze bekijk hoe je bestanden herstelt van een niet-koppelbare schijf op Mac-video is behoorlijk relevant.
Nog één ding: als dit direct na een macOS-update begon, negeer dat dan niet. Ik heb gezien dat oudere NTFS-hulpprogramma’s en beveiligingstools disenter-fouten veroorzaken na systeemupdates. Verwijder dat soort dingen voordat je iets al te geks doet.
Ik zou nog één invalshoek toevoegen die de anderen maar licht hebben aangestipt: machtigings- en aankoppelingsbeleidproblemen. Ik heb com.apple.diskmanagement.disenter error -119930868 zien optreden terwijl het bestandssysteem zelf grotendeels in orde was, maar macOS de koppeling weigerde door verouderde aankoppelpunten, beveiligingssoftware of een vreemd conflict in /Volumes.
Dingen die ik zou controleren als aanvulling op wat @jeff, @sternenwanderer en @mikeappsreviewer al hebben behandeld:
-
Zoek naar dubbele aankoppelmappen
In Terminal:ls /VolumesAls je oude mappen ziet met dezelfde schijfnaam, kan macOS vreemd reageren. Soms lost het verwijderen van een lege verouderde map in
/Volumesde weigering op. -
Probeer een handmatige alleen-lezen-koppeling
Dit is veiliger dan schrijfacties forceren:diskutil info /dev/diskX sudo mkdir /tmp/testmount sudo mount -o rdonly -t exfat /dev/diskXs1 /tmp/testmountVervang
exfatindien nodig door het echte bestandssysteem. Als het alleen-lezen wordt aangekoppeld, kopieer de gegevens dan onmiddellijk. -
Controleer op blokkades op de achtergrond
Antivirus, opschoonapps, NTFS-hulpmiddelen, back-upagents en zelfs sommige versleutelingshulpprogramma’s kunnen aankoppelingsgebeurtenissen onderscheppen. Ik ben het enigszins oneens met de gedachte van eerst gewoon reparaties uitvoeren, want als een kernel-extensie of hulpprogramma stoort, zullen reparatiepogingen het echte probleem niet oplossen. -
Bekijk logs in plaats van te gokken
Voer uit:log show --last 10m --predicate 'process == 'diskarbitrationd' || process == 'diskmanagementd'Dit kan laten zien of macOS de koppeling afwijst door een ongeldige superblock, een niet-ondersteund bestandssysteem, een slechte partitietabel of een fout die met machtigingen te maken heeft.
-
Als het een APFS-schijf is
Soms is de container zichtbaar, maar de volumes erin niet. Voer in dat geval uit:diskutil apfs listAls de container er verkeerd uitziet, blijf dan niet steeds opnieuw EHBO uitvoeren.
Als je prioriteit eerst de bestanden is, niet reparatie, dan is Disk Drill een redelijke volgende stap.
Voordelen van Disk Drill:
- kan schijven scannen die niet willen aankoppelen
- goed om bestanden veilig te stellen vóór het herformatteren
- eenvoudige interface vergeleken met meer handmatige herstelhulpmiddelen
Nadelen van Disk Drill:
- diepe scans kunnen lang duren
- de herstelkwaliteit hangt af van hoe beschadigd het bestandssysteem is
- geen wondermiddel als de hardware zwaar defect raakt
Dus mijn volgorde zou zijn: controleer logs, test een alleen-lezen/handmatige koppeling, elimineer softwareconflicten en gebruik daarna Disk Drill als het volume nog steeds niet wil aankoppelen maar de schijf wel wordt gedetecteerd. Als de schijf tijdens de test begint los te koppelen, stop dan daar en behandel het als een hardwareprobleem, niet als een macOS-probleem.


