Mijn externe harde schijf wordt plotseling niet meer aangekoppeld op mijn Mac en geeft de melding com.apple.diskmanagement.disenter error 0. Ik heb hulp nodig om uit te zoeken waardoor dit is veroorzaakt en hoe ik het kan oplossen, omdat er belangrijke bestanden op de schijf staan en ik geen toegang heb tot mijn gegevens.
Ik ben een tijd geleden tegen precies dezelfde ellende aangelopen. De schijf verscheen in Schijfhulpprogramma, bleef daar grijs staan en gaf de fout “com.apple.DiskManagement.disenter”. Wat ik op de harde manier heb geleerd is simpel. macOS ziet de hardware, maar het faalt op het bestandssysteemniveau, dus het volume wordt nooit gekoppeld.
Wat het bij mij veroorzaakte, was een van de gebruikelijke verdachten. Een schijf werd losgekoppeld zonder deze uit te werpen. Een exFAT-volume deed vreemd na verplaatsing tussen systemen. Een keer begon macOS de schijf op de achtergrond te controleren en leek het nooit klaar te komen. Elke keer hetzelfde resultaat: de schijf leek aanwezig maar was onbruikbaar.
Spring niet meteen naar wissen. Begin eerst met de minst risicovolle dingen.
1. Een vastgelopen fsck-controle beëindigen
Dit heeft het voor mij meer dan eens opgelost.
Wanneer een schijf verkeerd wordt losgekoppeld, start macOS vaak vanzelf fsck. Die controle is bedoeld om te helpen, maar als die vastloopt, blijft de schijf vergrendeld. Ik zag dit het vaakst bij grotere externe schijven en bij exFAT.
Open Terminal via Apps > Hulpprogramma's en voer daarna uit:
sudo pkill -f fsck
Typ je Mac-wachtwoord wanneer daarom wordt gevraagd. Je ziet de tekens niet terwijl je typt. macOS doet dat expres.
Als fsck degene was die de toegang blokkeerde, verschijnt de schijf soms vrijwel meteen weer. Als die alleen-lezen wordt aangekoppeld, blijf er dan vanaf en kopieer eerst je bestanden. Ik bedoel meteen.
2. Voer EHBO uit op de hele keten, niet alleen op het volume
Dit onderdeel wordt vaak overgeslagen.
Klik in Schijfhulpprogramma op Weergave en daarna op Toon alle apparaten. Je wilt de bovenste fysieke schijf zien, alle containers eronder en het volume zelf.
Voer daarna EHBO in deze volgorde uit:
fysieke schijf
container
volume
Ik heb een geval gehad waarin de eerste keer niets nuttigs opleverde en de tweede keer fouten opruimde. Dus als het één keer mislukt, zou ik het nog steeds opnieuw proberen voordat je verdergaat.
3. Log uit of test vanuit een andere macOS-gebruikersaccount
Ik weet dat dit willekeurig klinkt. Toch heb ik gezien dat DiskManagement kan vastlopen op gebruikersniveau.
Log uit bij je account. Meld je opnieuw aan en controleer de schijf opnieuw. Als je nog een andere lokale account op de Mac hebt, probeer het daar dan ook. Als de schijf in de andere account wordt gekoppeld, maakt je hoofdprofiel deel uit van het probleem, niet alleen de schijf. Ik heb gezien dat voorkeuren en machtigingen hier voor wat dom gedrag kunnen zorgen.
4. Kijk naar Time Machine als deze schijf ooit voor back-ups is gebruikt
Dit is me ooit overkomen en kostte me een hele avond.
Als de schijf vroeger een Time Machine-doel was, kan macOS er nog steeds aan vasthouden via back-uptaken of het beheer van lokale snapshots. Open Systeeminstellingen en schakel automatische Time Machine-back-ups voorlopig uit. Sluit de schijf daarna opnieuw aan en controleer het nog eens.
Niet het eerste waar ik de schuld aan zou geven, maar het is het proberen waard als de schijf een back-upgeschiedenis heeft.
5. Stop met het forceren van mounts als herstel belangrijk is
Als Terminal en EHBO nergens toe leiden, zou ik stoppen met reparatielussen.
Herhaalde pogingen om een beschadigd bestandssysteem geforceerd online te brengen, kunnen het verder ontregelen, vooral als de mapstructuur al kapot is. In dit stadium komt bestandsherstel vóór reparatie.
Ik zou een hersteltool gebruiken en de gegevens eerst naar een andere gezonde schijf overzetten. Disk Drill is één mogelijkheid. Het kan een schijf scannen, zelfs wanneer macOS weigert die op de normale manier te mounten. Het doel is nog niet om de schijf te repareren. Het doel is om je bestanden eruit te halen terwijl de ruwe data nog leesbaar is.
Mijn regel nadat ik hier een weekend aan had verloren, was simpel. Eerst herstellen. Daarna repareren. Wissen als laatste.
6. Alleen opnieuw formatteren nadat de bestanden veilig ergens anders staan
Zodra je gegevens eraf zijn, ga je terug naar Schijfhulpprogramma, selecteer je de fysieke schijf en wis je die daar.
De keuze van de indeling hangt af van waar de schijf gebruikt gaat worden:
Voor alleen Mac-gebruik: APFS of Mac OS Uitgebreid journaled.
Voor Mac en Windows: exFAT.
Ik zou de formattering op de Mac doen als de schijf heen en weer gaat tussen systemen. Ik heb op die manier minder vreemde aankoppelproblemen gehad.
Nog één ding. Werp externe schijven elke keer uit, zelfs als je haast hebt. Grote schijven hebben ook even nodig tijdens controles, dus geef EHBO wat tijd voordat je besluit dat het is vastgelopen. En ja, RAID vervangt nog steeds geen back-ups.
Fout 0 betekent meestal dat macOS de schijfbehuizing ziet, maar het volume weigert. Ik ben het eens met een deel van wat @mikeappsreviewer zei, maar ik zou eerst het hardwarepad controleren voordat je meer bestandsysteemherstellussen uitvoert. Ik heb dit vaker zien gebeuren door slechte USB-C-hubs, zwakke kabels en onvoldoende gevoede schijven dan mensen denken.
Probeer dit eerst.
-
Sluit de schijf rechtstreeks op de Mac aan.
Sla docks en hubs over.
Als hij een voeding heeft, gebruik die dan.
Als het een draagbare HDD is, probeer dan een andere kabel. Kabels gaan vaak kapot. -
Controleer of de schijf in Terminal wordt weergegeven.
Voer uit:
diskutil list
Als je de fysieke schijf ziet, noteer dan de identifier, zoals disk4.
Voer daarna uit:
diskutil info /dev/disk4
Zoek naar:
Protocol
S.M.A.R.T.-status
Alleen-lezen media
Bestandssysteempersoonlijkheid
Als de regel voor het bestandssysteem leeg of vreemd lijkt, is de partitietabel of de volumeheader beschadigd.
- Koppel vanuit Terminal aan, niet via Schijfhulpprogramma.
Voer uit:
diskutil mountDisk /dev/disk4
Als dat mislukt, probeer dan:
diskutil verifyDisk /dev/disk4
Dit test eerst de partitietabel. Schijfhulpprogramma verbergt een deel van deze info, wat eerlijk gezegd irritant is.
- Controleer systeemlogboeken.
Voer uit:
log show --last 10m | grep -i diskmanagement
en:
log show --last 10m | grep -i ‘I/O error’
Als je I/O-fouten ziet, stop dan met proberen de schijf te herstellen. Dat wijst op falende hardware, niet op een eenvoudig aankoppelingsprobleem.
- Als de schijf NTFS is, kan macOS die vaak lezen, maar gaat het niet goed om met schade.
Veel van deze fout 0-gevallen gebeuren na onveilig verwijderen in Windows. exFAT doet dit ook, maar NTFS is erger op Mac. Als je toegang hebt tot een Windows-pc, sluit hem daar dan op aan en voer uit:
chkdsk /f
Ik weet dat sommige mensen een hekel hebben aan platformoverschrijdende controles, maar voor NTFS is dit de juiste stap.
- Als je bestanden belangrijker zijn dan de schijf, schakel dan over naar herstelmodus voor je gegevens, niet voor macOS.
Disk Drill is een goede optie voor gegevensherstel van een externe harde schijf op Mac wanneer de schijf niet wil aankoppelen. Scan de schijf, sla herstelde bestanden op een andere schijf op en maak je daarna pas zorgen over reparatie.
Ook is dit de juiste denkwijze voor jouw geval: wanneer je moet stoppen met het gebruiken van een falende externe schijf en je moet richten op gegevensherstel
Nog iets wat mensen missen. Als de schijf klikt, uitspint, verdwijnt uit diskutil list, of steeds opnieuw verbinding maakt, stop dan nu. Dat is het gebied van fysieke uitval. Meer nieuwe pogingen = slechtere kansen. Als hij zichtbaar en stabiel blijft, heeft herstelsoftware nog steeds een redelijke kans.
Als je de output van diskutil list en diskutil info plaatst, kunnen mensen hier je vertellen of dit partitieschade is, bestandssysteembeschadiging, of dat de schijf begint te overlijden.
Ik zou één ding toevoegen dat zowel @mikeappsreviewer als @hoshikuzu alleen indirect hebben aangestipt: controleer of het volume wordt geblokkeerd door het beveiligingsbeleid van macOS, niet alleen door corruptie.
Dit gebeurt vaker met oudere HFS±schijven, vreemde partitietoewijzingen of schijven die zijn gebruikt in NAS-, DVR- of Linux-systemen. De schijf kan er in Schijfhulpprogramma prima uitzien, maar Finder weigert hem te koppelen en geeft toch de disenter-fout.
Een paar dingen die ik anders zou proberen:
- Voer in Terminal
mountuit en kijk of het volume al gedeeltelijk ergens vreemd is gekoppeld, zoals/Volumes/DriveName 1 - Controleer
/Volumesop spook-koppelingsmappen:
ls /Volumes
Als je duplicaten van de schijfnaam ziet, kan dat het koppelen verstoren - Probeer alleen-lezen te koppelen:
diskutil mount readOnly /dev/diskXsY
Als dat werkt, kopieer dan eerst de gegevens en stop daar - Start op in Veilige modus en test de schijf daar. Dat schakelt veel rommel van derden uit die kan storen, vooral NTFS-hulpprogramma’s en antivirussoftware
- Als je Paragon, Tuxera, antivirus of schijfmonitoringtools gebruikt, verwijder ze dan of schakel ze tijdelijk uit
Soms is Finder trouwens de leugenaar, niet de schijf. Controleer of het volume in Terminal verschijnt, zelfs wanneer Finder doet alsof het niet bestaat.
Als de gegevens belangrijk zijn, ben ik het er enigszins mee oneens om te veel controle-/reparatiepogingen te doen. Na 2 of 3 mislukte koppelingspogingen zou ik overstappen op herstel. Disk Drill is meestal de praktische keuze voor herstel van externe harde schijven op Mac, omdat het de schijf kan scannen, zelfs wanneer macOS die normaal niet wil koppelen.
Als dit een externe Seagate-schijf is, is hun eigen pagina over het oplossen van Seagate-schijfkoppelings- en Schijfhulpprogramma-fouten op macOS ook het bekijken waard.
Korte versie: als de schijf stabiel en zichtbaar is, test dan alleen-lezen en Veilige modus. Als hij verdwijnt, klikt of steeds opnieuw verbinding maakt, stop dan met eraan sleutelen en herstel eerst de bestanden.
