macOS 26 dispose de son propre système de conteneurs. Cette technologie surtout utilisée dans le monde des serveurs permet de faire tourner des processus dans un environnement virtuel allégé. N’en ayant pas vraiment l’usage au quotidien, je n’avais pas testé jusque-là cette relecture de Docker proposée par Apple. Néanmoins, je l’ai installée pour les besoins d’un article et j’ai créé deux instances de Home Assistant pour comprendre son fonctionnement. Un test sans histoire, jusqu’au moment de réaliser que j’avais sans le savoir ajouté plus de 2 To sur mon Mac Studio !
Mon ordinateur en compte 8 depuis que j’ai remplacé le SSD par défaut, alors c’est pour ça que j’ai pu passer à côté. En faisant un tour dans le Finder, j’ai toutefois noté un espace restant qui tournait autour des 2,5 To, une valeur anormalement basse. Il ne m’a fallu pas longtemps pour repérer le coupable : chaque conteneur créé avec le système d’Apple affiche plus de 550 Go dans le gestionnaire de fichiers de macOS. Ajoutez à cela quelques « snapshots », des instantanés de sauvegarde, de la même taille et on arrive vite aux 2,2 To utilisés par l’ensemble.
Ces valeurs m’ont évidemment surpris. Home Assistant est un outil puissant, certes, mais il est loin de nécessiter une telle place. Pour vous donner une idée, une installation avec Docker représente en gros 1,5 à 2 Go et certainement pas 300 fois plus, comme c’est le cas ici. En fouillant un petit peu plus, j’ai noté que le fichier rootfs.ext4 occupait tout l’espace à l’intérieur d’un dossier associé à chaque conteneur. Cela correspond au système de fichiers Linux utilisé sous le capot : Home Assistant, dans mon exemple, ne tourne pas directement sous macOS, il nécessite une couche de virtualisation intermédiaire.
Cela m’a mis la puce à l’oreille et vérifications faites, ce fichier ne pèse pas 550 Go sur le SSD de mon Mac Studio. Il s’agit en réalité d’une sorte de disque virtuel qui peut occuper jusqu’à 550 Go, mais dont l’espace effectivement utilisé dépendra des données stockées dans l’instance. Pour une raison qui m’échappe un peu, le Finder reste toujours aussi mauvais pour évaluer la taille de ces fichiers. Les outils plus bas niveau accessibles depuis le terminal sont plus proches de la réalité, avec une grosse dizaine de gigaoctets sollicités pour tous les environnements virtuels, dont environ 2,5 Go pour chaque fichier rootfs.ext4. Si cela reste nettement plus élevé qu’avec Docker, c’est tout de même plus raisonnable.
Malheureusement, les outils de sauvegarde auront sans doute du mal à gérer ces fichiers extensibles, avec des conséquences plus gênantes que des chiffres faussés dans le Finder. Ma sauvegarde Backblaze a grossi d’un coup de 1,65 To et si elle n’était pas illimitée, ma facture aurait sérieusement augmenté d’un coup et sans raison. Sur le projet GitHub, on trouve aussi plusieurs tickets ouverts en lien avec Time Machine. En particulier, les sauvegardes sur un NAS ou tout autre appareil via SMB peuvent être bloquées par ces données et la seule option semble alors être d’exclure le dossier complet.
Le bug est en tout cas connu depuis l’été dernier et il n’y a pas vraiment de bonne solution à ce jour. Un contributeur indiquait en février dernier que la gestion de Time Machine allait être corrigée… un jour, même si cela n’a manifestement pas été une priorité jusque-là. Des commentaires récents prouvent que la sauvegarde des conteneurs pose toujours problème avec la version finale de macOS 26. Ma sauvegarde Time Machine se faisant sur un SSD relié en USB au Mac, tout se fait avec APFS et ses instantanés et mon stockage externe n’est pas saturé.
Si vous comptez utiliser cette fonction de macOS, n’oubliez en tout cas pas de vérifier vos sauvegardes. En attendant un vrai correctif, le mieux est sans doute d’exclure ce dossier :
~/Library/Application\ Support/com.apple.container
