macOS 27 et CoreStorage : volumes HFS+ bloqués

Ce qui change avec macOS 27 pour CoreStorage

CoreStorage est une technologie de gestion de volumes utilisée par des versions plus anciennes de macOS. Elle a notamment servi de couche de stockage pour des volumes HFS+ chiffrés. Plus récemment, Apple a privilégié APFS, le système de fichiers des versions actuelles. Mais le fait qu'une technologie soit dépréciée ne veut pas dire qu'elle cesse instantanément de fonctionner : dans la vraie vie, certains outils anciens peuvent rester nécessaires tant que des données y dépendent.

C'est ce qui ressort du retour d'expérience publié par Wade Tregaskis sur macOS 15 Sequoia. À l'époque, certaines opérations étaient déjà instables : des volumes devaient parfois être déverrouillés manuellement au démarrage, et la conversion de certains volumes HFS+ vers APFS échouait. Malgré ça, les données restaient accessibles et les volumes pouvaient encore être utilisés dans l'ensemble.

Avec macOS 27, le tableau est plus dur. Les méthodes habituelles de montage échouent, y compris via Utilitaire de disque et avec diskutil. La conversion vers APFS peut aussi échouer, et l'effacement peut rester bloqué avec une erreur du type ressource occupée. Autrement dit, ce n'est pas seulement un bouton ou une option retirée : plusieurs façons de gérer le disque semblent touchées.

Cela dit, il y a une limite à garder en tête : ce constat s'appuie sur un cas documenté. Ce n'est pas une annonce générale d'Apple indiquant que chaque volume CoreStorage est inutilisable sur toute configuration de macOS 27. La version du système, le matériel et l'état exact du volume peuvent changer le résultat. Le plus prudent est donc de parler d'une incompatibilité sérieuse signalée dans un contexte précis, pas d'une règle universelle déjà prouvée partout.

Autre point qui peut brouiller le diagnostic : au démarrage, le message observé évoque macOS 28 comme future fin de prise en charge, alors que le problème décrit apparaît déjà sous macOS 27. Cette contradiction rend l'interprétation plus délicate. Un avertissement de compatibilité ne suffit pas, à lui seul, à dire si le volume est réellement lisible et quelle action est sans risque.

Quels symptômes permettent d'identifier le problème

Le premier signe est souvent un échec de montage, automatique au démarrage ou manuel dans Utilitaire de disque. Dans le cas documenté, l'erreur affichée est peu parlante : com.apple.DiskManagement.disenter error 49,153. diskutil mount échoue aussi, mais avec un message qui parle de volume verrouillé et conseille de le déverrouiller.

Ce point peut tromper. La commande de déverrouillage peut répondre que le volume est déjà déverrouillé et associé à un identifiant de disque. De son côté, la liste CoreStorage peut afficher un état « Online » et « Unlocked ». Le problème n'est alors pas forcément le mot de passe ou la clé : le système « voit » bien le volume logique, mais n'arrive pas à monter le volume comme il faut.

On peut aussi voir le problème lors d'une tentative de conversion vers APFS. La conversion démarre, vérifie le volume, lance le convertisseur, puis s'arrête avec l'erreur -69860. Dans le scénario décrit, l'échec intervient pendant la conversion, et le système remet le type précédent. Du coup, répéter la commande ne garantit rien : convertir des données précieuses demande de la prudence.

Enfin, l'erreur « Resource busy » (ressource occupée) apparaît pendant certaines tentatives de montage en écriture ou d'effacement. Sur le moment, on peut croire qu'un processus « tient » le disque. Pourtant, dans le rapport, l'auteur dit ne pas avoir trouvé de processus pertinent avec les outils habituels, notamment lsof. L'erreur seule ne permet donc pas d'identifier la cause ni de conclure qu'un simple redémarrage ou la fermeture d'une appli suffira.

Peut-on accéder aux données sans effacer le disque

Dans le cas rapporté, oui, mais uniquement en lecture seule. L'auteur a contourné les outils de montage habituels et a appelé directement mount_hfs avec l'option rdonly. La commande a permis de lister le contenu du volume et d'accéder aux dossiers. C'est suffisant pour copier des fichiers, mais ce n'est pas une preuve que le volume fonctionne « normalement », ni que l'on peut le réparer en place.

La forme générale de la commande ressemblait à ceci :

sudo mkdir -p /Volumes/Smash
sudo mount_hfs -o rdonly /dev/disk27 /Volumes/Smash

Les valeurs Smash et disk27 correspondent à l'exemple. Sur votre machine, il faut remplacer par le nom de montage que vous voulez et par l'identifiant réellement attribué à votre volume logique. Comme la commande utilise sudo, elle s'exécute avec des privilèges élevés. Si vous avez le moindre doute sur le périphérique ciblé, ne lancez pas.

Le paramètre rdonly force un montage en lecture seule. C'est cohérent si l'objectif est simplement de récupérer des fichiers : vous évitez les modifications volontaires du volume pendant l'accès. Cela ne remplace toutefois ni une sauvegarde, ni une vérification de l'état des données, ni un examen de la fiabilité matérielle. Si le contenu est critique, commencez par copier les fichiers prioritaires vers un autre support suffisamment grand, puis vérifiez que les fichiers copiés s'ouvrent correctement.

Le montage en écriture n'a pas fonctionné dans le scénario d'origine. Les tentatives se terminaient par « Resource busy », même sans processus utilisateur clairement identifié comme en train d'utiliser le volume. Il n'est donc pas judicieux de présenter cette commande comme une « réparation » complète, ni de supprimer l'option de lecture seule en espérant débloquer l'écriture.

Comment fonctionne la procédure d'effacement rapportée

La procédure décrite par l'auteur ne « récupère » pas le volume. Elle sert à supprimer les structures CoreStorage, puis à effacer le support pour pouvoir le réutiliser après redémarrage. Et surtout : si vous n'avez pas déjà récupéré et vérifié les données, ce n'est pas une étape « d'essai ». C'est potentiellement destructeur.

La première commande tentée était diskutil cs delete, appliquée à l'identifiant du groupe logique CoreStorage. Elle semblait échouer : macOS ne pouvait pas créer un nouveau système de fichiers sur le volume physique, avec une erreur « Resource busy ». Pourtant, après cette tentative, la liste CoreStorage indiquait que le groupe était hors ligne et que les volumes logiques avaient disparu.

Dans l'exemple publié, une seconde tentative de suppression du même groupe échouait ensuite avec l'erreur -69783. Et surtout, le blocage ne se levait pas tout de suite : l'effacement du volume physique restait impossible tant que macOS le considérait comme occupé. L'auteur a alors redémarré la machine. Après le redémarrage, l'effacement du volume a pu être effectué.

Ce scénario suggère que « occupé » était lié à la présence persistante des volumes logiques, même après leur suppression apparente. Mais ça ne prouve pas le mécanisme exact. Et ça ne garantit pas que la même séquence fonctionnera sur tous les Mac ou tous les disques. À lire comme un contournement rapporté, pas comme une procédure validée « officiellement » par Apple.

Quelle décision prendre avant de mettre à jour

La décision dépend d'abord de la valeur des données, puis de l'usage du volume. Un disque de travail secondaire, dont le contenu est sauvegardé, n'appelle pas la même conduite qu'un volume chiffré contenant l'unique copie de documents professionnels. Le nom de la techno (CoreStorage) est secondaire ici. Le vrai risque, c'est de dépendre d'un format ancien dont les outils système peuvent ne plus gérer correctement la situation.

Si vous utilisez encore un volume HFS+ chiffré via CoreStorage, faites un inventaire avant une mise à jour majeure : quels disques sont concernés, quelles données y résident, où se trouve la sauvegarde, et comment vérifier qu'elle fonctionne vraiment. Une copie « présente » n'est pas une garantie tant qu'on n'a pas testé. Ouvrez quelques fichiers, contrôlez les dossiers importants, et assurez-vous que la sauvegarde est stockée ailleurs.

Si votre Mac est déjà sous macOS 27 et que le volume est accessible en lecture seule, récupérez d'abord vos données avant d'essayer de convertir ou d'effacer. Si le volume est inaccessible et que les données sont irremplaçables, évitez de multiplier les opérations sur l'original. Dans le cas documenté, les outils intégrés ne donnent pas une solution complète pour réparer en place ou convertir de façon fiable.

Pour un disque que vous comptez réutiliser et dont les données sont sauvegardées, la procédure rapportée peut aider à comprendre pourquoi un effacement échoue d'abord puis qu'un redémarrage change la donne. Mais elle reste destructrice et liée au scénario précis. Si vous observez des erreurs différentes, ne transposez pas automatiquement : l'état des couches de stockage, les identifiants et la situation du disque peuvent varier.

Le message de compatibilité évoquant macOS 28 ne devrait pas être le seul déclencheur. Le problème décrit existe déjà sous macOS 27, et la formulation de l'avertissement est contradictoire. La décision doit surtout tenir compte de l'accès réel au volume et de la qualité de vos sauvegardes, pas d'une date affichée dans une boîte de dialogue.

Conclusion

Le signalement concernant macOS 27 décrit une dégradation concrète pour certains volumes HFS+ chiffrés via CoreStorage : le volume peut sembler déverrouillé, tout en restant inaccessible aux outils habituels. Dans le cas rapporté, un montage en lecture seule a permis de récupérer des fichiers. Mais aucune conversion ni réparation en place n'a été trouvée. L'effacement, lui, a demandé une séquence détournée et a détruit les données.

La décision la plus sûre reste simple : sauvegardez et vérifiez d'abord, récupérez les fichiers avant toute suppression, et ne transformez pas un contournement rapporté en procédure universelle. Si vos volumes CoreStorage contiennent encore des données importantes, ne repoussez pas la migration tant que vous n'avez pas confirmé que votre copie est réellement récupérable et exploitable.