- Das Startvolume eines M2 MacBook Pro füllte sich während eines Steam-Spieledownloads so sehr, dass nur noch 41 KB übrig waren; macOS geriet in einen Zustand, in dem es nicht einmal mehr Dateien löschen konnte
- Das Leeren des Papierkorbs im Finder,
rmundfind -exec rmim Terminal sowie das Löschen von Time-Machine-Snapshots im Festplattendienstprogramm scheiterten allesamt mit Fehlern der Art „No space left on device“ - Nach einem Neustart blieb auch der Bootvorgang mittendrin hängen; selbst über recoveryOS und Share Disk auf Apple silicon ließ sich das Laufwerk zwar an einem anderen Mac einhängen, das Löschen aber nicht erzwingen
- Nach dem Löschen des Laufwerks und einer Neuinstallation von macOS wurde eine Time-Machine-Wiederherstellung versucht, doch es folgten Abbrüche bei der Ventura-Wiederherstellung, Versionsunterschiede zwischen Sonoma 14.4 und dem bisherigen 14.3.1 sowie fehlgeschlagene SMB/Samba-Netzwerk-Mounts
- Am Ende wurde das neueste Time-Machine-Disk-Image auf eine externe 1-TB-SSD kopiert und die Dateien aus dem Home-Verzeichnis sowie Apps manuell wiederhergestellt; wenn voller Speicher und scheiternde Backup-Wiederherstellung zusammenkommen, ist das selbst für erfahrene Nutzer schwer zu bewältigen
Ein Mac, auf dem Speichermangel sogar das Löschen blockierte
- Der Speicherplatz des M2 MacBook Pro lief voll, während ein legal bei Steam gekauftes Spiel heruntergeladen wurde
- Obwohl das Laufwerk gefährlich voll wurde, stoppte macOS den großen Steam-Download nicht; auf dem Startvolume blieben nur 41 KB übrig
- Die meisten wichtigen Dateien lagen in der Cloud, und es gab keine lokalen großen Dateien, die unbedingt erhalten bleiben mussten
- Das Problem war nicht einfach nur zu wenig Speicherplatz, sondern ein Zustand, in dem das Betriebssystem auf keine Weise mehr Dateien löschen konnte
Vermutete Ursache: Steam-Download und lokale Time-Machine-Snapshots
- Möglicherweise konnte macOS wegen der Gigabit-Internetverbindung und der großen Steam-Dateien den Speicherzuwachs nicht mehr kontrollieren
- Gleichzeitig bestand der Verdacht, dass macOS lokale Time-Machine-Snapshots erstellte
- macOS hält Snapshots vor, um auch während Backups auf ein externes oder Netzwerk-Time-Machine-Ziel lokale Backups der letzten 24 Stunden bereitzustellen
- Die Steam-Datei wirkte nach außen wie eine einzige riesige Datei, könnte aus Sicht von Time Machine aber anders behandelt worden sein
- Möglicherweise kollidierten die tatsächliche lokale Datei und die speziell erzeugten Snapshots; die genaue Ursache ist jedoch nicht gesichert
Alle Löschversuche schlugen fehl
- Papierkorb im Finder leeren scheiterte über
File > Empty Trash- Die Fehlermeldung lautete: „The operation can’t be completed because the disk is full“
- Das Terminal ließ sich starten, doch der Standard-Unix-Befehl
rmfunktionierte nicht- Die Fehlermeldung lautete: „No space left on device“
- Auch eine Alternative auf Basis von
find, bei der große Dateien gesucht und anschließend per-execmitrmgelöscht werden sollten, scheiterte
- Auch im Festplattendienstprogramm wurde versucht, Time-Machine-Snapshots auf dem APFS-Startvolume auszuwählen und zu löschen, doch es scheiterte an derselben Grenze
- Normalerweise belegen Snapshots nur den Speicherplatz, der für die Unterschiede zum vorherigen Snapshot benötigt wird
- Auch in diesem Fall trat jedoch der Fehler „no space left“ auf
Neustart, recoveryOS und Share Disk halfen ebenfalls nicht
- In der Hoffnung auf eine Cache-Bereinigung wurde neu gestartet, doch der Mac bootete danach nicht mehr normal
- Der Fortschrittsbalken lief etwa bis zur Hälfte und der Vorgang scheiterte wiederholt
- In recoveryOS wurden Reparaturen im Festplattendienstprogramm und Schritte zur Neuinstallation versucht, während das Startvolume nicht eingehängt war; Terminal-Befehle lieferten jedoch denselben Fehler
- Mit der Funktion Share Disk von Apple silicon sollte das betroffene Laufwerk an einem anderen Mac eingehängt werden
- Über die Samba-basierte Festplattenfreigabe sollte das Löschen erzwungen werden, was jedoch fehlschlug
Weitere Probleme während der Time-Machine-Wiederherstellung
- Es gab Time-Machine-Backups, einschließlich eines Backups vom Vorabend, und da die meisten wichtigen Daten in der Cloud lagen, war eine vollständige Wiederherstellung nicht zwingend erforderlich
- Zunächst wurde das Laufwerk gelöscht und über macOS Recovery Ventura neu installiert, das Standardsystem, mit dem das MacBook Pro ausgeliefert worden war
- Beim Start von macOS wurde mit dem Migrationsassistenten auf das Netzwerk-Time-Machine-Backup zugegriffen, und einige Wiederherstellungspunkte wurden abgewählt, um genügend freien Speicher zu behalten
- Während der Wiederherstellung blieb Ventura mittendrin hängen und ließ sich danach nicht fortsetzen
- Anschließend wurde der Mac auf das damals genutzte macOS Sonoma aktualisiert
- Das Upgrade war erfolgreich, installiert wurde jedoch Version 14.4
- Auf dem bisherigen Mac war 14.3.1 installiert gewesen
- Der Versuch, direkt beim Start wiederherzustellen, wurde wegen des Versionsunterschieds nicht zugelassen
Netzwerk-Mount-Problem von Time Machine unter Sonoma 14.4
- Nach dem Anlegen eines regulären Sonoma-Benutzerkontos wurde der Migrationsassistent gestartet
- Der Migrationsassistent fand und erkannte den Netzwerk-Mac, der die Time-Machine-Backups verwaltete
- Das Backup-Volume des Kindes konnte jedoch nicht eingehängt werden; wiederholt erschien „Mount failed“
- Eine Suche in Foren ergab, dass der SMB/Samba-basierte Netzwerk-Mount-Vorgang für Time-Machine-Wiederherstellungen unter Sonoma defekt war und keine Lösung gefunden wurde
- Dieses Problem schien auch unter macOS 14.4 weiterhin zu bestehen
Endgültige Wiederherstellung: Backup auf externe SSD kopieren und manuell migrieren
- Auf eine vollständige Wiederherstellung per Migrationsassistent wurde verzichtet; stattdessen wurden nur die benötigten Apps und Dateien manuell wiederhergestellt
- Auf dem Mac, der die Netzwerk-Backups verwaltet, wurde das Disk-Image des betreffenden Computers doppelt angeklickt und das Passwort des Time-Machine-Volumes eingegeben
- Für das Netzwerk-Time-Machine-Volume war stets ein separates Passwort gesetzt
- Das Disk-Symbol mit dem neuesten Zeitstempel wurde gesucht und auf eine leere externe 1-TB-SSD kopiert
- Die externe SSD wurde an das temporäre Konto auf dem MacBook Pro angeschlossen, um die benötigten Dateien zu übertragen
- Enthalten waren die meisten Inhalte der Ordner im Home-Verzeichnis
- Große Download-Dateien und einige nicht benötigte Videodateien wurden ausgeschlossen
- Die externe SSD sollte vorerst aufbewahrt werden, um bei fehlenden Dateien weitere Wiederherstellungen vornehmen zu können
Nicht ausprobierte Alternativen
- Das Time-Machine-Laufwerk für Netzwerk-Backups hätte auf dem Backup-verwaltenden Mac ausgehängt und direkt an den Mac des Kindes angeschlossen werden können
- In diesem Fall wäre es möglicherweise als Quelle für den Migrationsassistenten erschienen
- Aus dem eingehängten Time-Machine-Disk-Image hätte man auch die virtuelle Festplatte kopieren können, sodass die externe 1-TB-SSD wie ein Mac-Quellvolume gewirkt hätte
- Ob diese Methode tatsächlich funktioniert hätte, wurde nicht überprüft
- Im Erfolgsfall wäre möglicherweise eine direkte Wiederherstellung per Migrationsassistent möglich gewesen
- Da bereits mehrere Stunden Arbeit und mehr als ein Tag an Versuchen zusammengekommen waren und der Nutzer keine perfekte Wiederherstellung auf Verzeichnisebene unbedingt wollte, wurden keine weiteren Experimente unternommen
1 Kommentare
Hacker-News-Kommentare
Für den Autor wäre es möglicherweise besser gewesen, den Mac von einem externen Speichermedium zu booten und dann unnötige Dateien von der internen Festplatte zu löschen: Use an external storage device as a Mac startup disk
Überraschend war, dass bei Macs mit Apple Silicon beim externen Booten nicht alle Ports gleichwertig sind.
Wenn man macOS auf einem Speichermedium installiert, sollte man bei Mac-Notebooks den ganz linken USB-C-Port auf der linken Seite meiden; auch bei iMac/Mac mini/Mac Studio/Mac Pro gibt es je nach Modell bestimmte USB-C-Ports, die man vermeiden sollte.
Nach Abschluss der Installation soll es egal sein, an welchen Port man es anschließt.
Der Autor bootete in das separate recoveryOS und versuchte dann, Dateien von der Haupt-Systempartition zu löschen, aber
rmscheiterte mit demselben FehlerNo space left on device.Daher hätte die von anderen erwähnte Methode, Dateien mit
echo -n >filezu kürzen, möglicherweise funktioniert.Mit etwas Wissen über die Struktur von HFS+-Volumes vermute ich, dass auch die Journal-Datei voll war; da Löschen Schreibvorgänge ins Journal und je nach Fall sogar dessen Erweiterung erfordert, scheint ein merkwürdiger Zustand entstanden zu sein, in dem das Löschen selbst zumindest vorübergehend mehr Speicherplatz benötigt.
macOS schrieb weiter Dateien, bis auf dem Laufwerk nur noch 41 KB übrig waren.
Ich habe NTFS und FAT32 versehentlich schon bis auf 0 Byte gefüllt, und selbst dann konnte man noch etwas löschen.
Beim Durchstöbern von Foren wirkt es so, als habe Sonoma den SMB/Samba-basierten Netzwerk-Mount-Prozess für Time-Machine-Wiederherstellungen kaputtgemacht, und auch in 14.4 scheint es noch keine Lösung zu geben.
Meiner Erfahrung nach ist SMB seit etwa 10.12–10.13 schwer vertrauenswürdig und viel zu fehleranfällig geworden; inzwischen wirkt es so, als kümmere Apple sich nicht einmal mehr darum, ob das überhaupt funktioniert.
Ich möchte mir nicht vorstellen, was Menschen ohne jahrzehntelange Mac-Erfahrung tun würden, wenn sie auf so eine Kette von Systemausfällen stoßen.
Ich habe zwar keine jahrzehntelange Mac-Erfahrung, aber in so einer Situation hätte ich zuerst
fsckversucht; seltsam, dass es hier nicht erwähnt wird.Wenn ich den Inhalt der Festplatte nicht auf eine andere kopieren, formatieren und zurückspielen könnte, würde ich wohl in der APFS-Dokumentation (https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf) nachsehen und mit
ddsowie einem Hex-Editor herausfinden, welche Stelle man korrigieren müsste, um freien Speicher zu schaffen.Anschließend findet die Garbage Collection Dateien, die nicht mehr zum aktiven Baum gehören, und gibt ihren Speicherplatz zurück.
Normalerweise werden Änderungen gebündelt, um die Menge an Baumänderungen beherrschbar zu halten; durch dieses Design ist ein Dateisystem-Snapshot einfach eine weitere Referenz auf einen bestimmten Baum.
Dieser Prozess benötigt Speicherplatz, aber CoW-Dateisysteme reservieren dafür normalerweise aus genau diesem Grund Notfallspeicher.
Als ich vor ein paar Jahren auf einem per 10GbE mit einem großen NAS verbundenen Hackintosh mit BlackMagic Disk Speed Test gemessen habe, kam Windows-SMB auf 900 MB/s, macOS-SMB auf 200 MB/s und macOS-NFS sowie AFP jeweils auf 1000 MB/s.
macOS-Funktionen im professionellen Arbeitsumfeld sind leider lächerlich.
AFP gilt zwar als tot, funktioniert auf meinem Mac Pro als Client aber weiterhin gut, und die Performance ist so viel besser als bei SMB, dass es fast wie eine Komödie wirkt.
Wenn man sie bis zum Anschlag füllt, kann es Probleme geben.
BTRFS versucht, auf Read-only umzuschalten, solange noch Metadaten-Speicher übrig ist, sodass man es im Safe Mode erneut mounten und etwas löschen kann; einen perfekten Schutzmechanismus gibt es aber nicht.
NTFS und FAT32 sind meines Wissens keine Journaling-Dateisysteme.
Bei meinem ersten Job ist mir so etwas passiert
Ich habe versehentlich einen Cluster mit Job-Dateien vollgeschrieben, und der Systemadministrator fing an, mir E-Mails zu schicken, ich solle das schnell beheben, aber
rmfunktionierte nichtDamals habe ich gelernt, dass Dateien zu kürzen meistens auch dann noch geht, wenn Löschen nicht funktioniert. Wenn also
rm foonicht geht, klappt oftcat /dev/null > foo:>filepathAllerdings kann es sein, dass manche Dateisysteme selbst das nicht mehr schaffen
In so einem Fall muss man hoffen, dass das Dateisystem Vergrößern, Verkleinern oder temporären zusätzlichen Speicher unterstützt, oder dass das darunterliegende System das Hinzufügen/Entfernen von Backing Storage erlaubt
Wie bei btrfs kann auch ein eigener Befehl nötig sein, um wieder auf eine Struktur für ein einzelnes Blockgerät zurückzukehren
Deshalb ließ ich den Backup-Prozess regelmäßig Müll-Daten direkt nach /dev/null schicken, und dieser schmutzige Hack läuft vermutlich immer noch
/dev/nullist ziemlich magisch und eine Lektüre wert>fileDateisystemformate des 21. Jahrhunderts sind deutlich komplexer als UFS, und Funktionen wie Snapshots und Journaling schaffen neue Wege, wie ein Dateisystem sich selbst in einen Deadlock bringen kann
Am Ende musste ich es mit
truncatewiederherstellenIch wusste zwar, dass ZFS für solche Situationen besser ist, aber dieses absinkende „Oh … verdammt“-Gefühl, wenn man merkt, dass man es wirklich vermasselt hat, blieb trotzdem
Time Machine scheint stetig schlechter zu werden
Ich weiß nicht, warum es keinen Anreiz gibt, es stabil und korrekt funktionierend zu machen
Nachdem ich erlebt habe, dass sparse bundles beschädigt wurden und ich ein neues Backup starten musste oder Funktionen versagten, habe ich inzwischen das Gefühl, dass es sich kaum noch lohnt, Time Machine einzurichten
Das steht in völligem Gegensatz zu den iOS/iPadOS-Backups, die bei mir jedes Mal gut funktioniert haben
Apple will, dass Leute alles in iCloud sichern und so den Service-Umsatz steigern
Ich betreibe Time Machine seit Jahren auf mehreren Macs über Samba-Freigaben und habe eher nur Verbesserungen gesehen
Früher wurden Time-Machine-sparse-bundles häufig beschädigt, sodass ich sie neu erstellen oder einen früheren ZFS-Snapshot wiederherstellen und weitermachen musste
Damals war es, glaube ich, AFP und nicht SMB
In letzter Zeit hatte ich auf keinem Gerät solche Probleme, wobei ich in
smb.confbestimmte Flags aktiviert habe, die für Time-Machine-Backups empfohlen werdenUmgekehrt hat ZFS slop space, um zu vermeiden, dass einem Dateisystem mitten in großen Operationen der Platz ausgeht und es hängen bleibt
Standardmäßig werden 3,2 % des Volume-Speichers reserviert, bis maximal 128 GB
Wenn man also den Linux-Kernel-Tuningwert
spa_slop_shiftändert und den slop space reduziert, kann man bis zu 128 GB Bonus-Speicher zurückgewinnen, um eine Dateilöschung erfolgreich abzuschließen: https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#spa-slop-shiftAus solchen Gründen war die Reservierung eines bestimmten Prozentsatzes des Plattenplatzes schon Jahrzehnte vor ZFS oder Linux eine gängige Funktion „echter“ Dateisysteme
Ähnlich wie die meisten MS-DOS-Shareware-Terminalprogramme der 1980er Datei-Downloads über Verbindungen mit begrenzter Bandbreite sehr gut beherrschten, während das heutige MS Windows selbst bei einer eigentlich trivialen Aufgabe dieser Art miserabel ist
Details stehen in
man tune2fsDasselbe gilt für die meisten anderen modernen oder auch nicht besonders modernen Dateisysteme
Soweit ich mich erinnere, hatte auch UFS unter SunOS in den 1980ern so etwas: https://en.wikipedia.org/wiki/SunOS
Es fällt Leuten schwer zu verstehen, dass zum Löschen von etwas tatsächlich mehr Speicherplatz nötig sein kann, sei es vorübergehend oder dauerhaft
Andere Kommentare haben ausführlich erklärt, warum moderne Dateisysteme mit Snapshots, Journaling und Ähnlichem beim Löschen aus dem freien Speicher allozieren müssen
In anderen Bereichen musste man ähnlich während der ersten zehn Jahre von Wikipedia oft erklären, dass der Versuch, durch das Löschen von Seiten Serverplatz zu sparen, tatsächlich den gegenteiligen Effekt hatte
Denn zumindest seit etwa 2004 fügte ein Löschvorgang der internen Datenbank einen Datensatz hinzu
Im ZOO-Archivformat von Rahul Dhesi bestand das Löschen eines Eintrags nur darin, ein Flag in einem Header-Datensatz zu setzen, und es gab auch eine VMS-artige Dateiversionierung, bei der das Hinzufügen einer neuen Version die alte Version nicht überschreibt
Zu Zeiten von MS/DR/PC-DOS und FAT konnte es, wenn ein Undelete-Utility installiert war, beim Löschen einer Datei mehr Speicherplatz benötigen, weil ein neuer Eintrag in einer Datenbank mit Wiederherstellungsinformationen gespeichert wurde
Einige ältere Disk-Kompressionsprogramme komprimierten sogar Metadaten, sodass in seltenen Fällen eine Metadatenänderung die Kompressionsrate verändern und die von außen sichtbare Volume-Größe tatsächlich vergrößern konnte
Die Vorstellung, dass man durch Löschen Speicherplatz freigibt, ist weit verbreitet, aber streng genommen nicht immer richtig
Im Oktober 2018 hatte ich dasselbe Problem und habe es in der folgenden Stack-Overflow-Frage festgehalten.
Zum Glück hatte ich eine zusätzliche APFS-Partition, die ich entfernen konnte, um Speicherplatz freizugeben.
Es hat eine ganze Weile gedauert, das herauszufinden, und in der Zwischenzeit war ich ziemlich in Panik.
https://apple.stackexchange.com/questions/338721/disk-full-terminal-in-recovery-mode-won-t-delete-files-boot-kernel-panics
Direkt nach dem Update auf macOS Mojave füllte ich beim Erstellen einer
.dmgdie Festplatte, und das System fror ein.Nach dem Neustart kam es zu einer Kernel Panic; ich bootete in den Recovery Mode, mountete die Festplatte und führte im Terminal
rm /path/to/large/fileaus, bekam aberNo space left on device.Im Kern war es dasselbe Problem wie in diesem Unix-Thread von 2008: https://www.unix.com/linux/69889-unable-remove-file-using-rm-disk-space-full.html
Auch
echo x > /path/to/large/filehalf nicht; ich brauchte einen anderen Vorschlag als „Laufwerk löschen und aus dem Backup wiederherstellen“.Ähnlich wie ältere Unix-Dateisysteme 5 % für root reservierten.
Wenn man die Partition für virtuellen Speicher löscht, kann das — vorausgesetzt, sie ist groß genug — genügend Platz zurückgeben, um Dateien löschen zu können.
Denn Container werden erst dann tatsächlich zugewiesen, wenn sie genutzt werden.
Beeindruckend.
Eine Situation, in der sogar
rmfehlschlägt, habe ich noch nie erlebt, aber die Unannehmlichkeit, moderne Macs mit höchstens 256 GB internem Speicher zu nutzen und zu verwalten, kenne ich.Deshalb lege ich mir meist eine Platzhalterdatei von etwa 16 GB an.
Wenn der Speicher ohnehin voll ist und Updates oder andere Arbeiten blockiert, kann ich einfach diese Datei löschen, ohne mit
ncduchirurgisch aufräumen zu müssen.Zum Beispiel, indem man zum Preis einer Arbeitsstunde eines Mitarbeiters oder Geräts ein neues Laufwerk kauft, das viermal so groß ist wie das bisherige.
Auf dem iPhone habe ich etwas Ähnliches erlebt.
Der Speicher war so voll, dass das Löschen von etwas praktisch so wirkte, als passiere gar nichts.
Nach einem Neustart konnte ich mich nicht mehr anmelden, und nach einem weiteren Neustart geriet es in eine Boot-Schleife.
Nach noch einem Neustart startete es in einen inkonsistenten Zustand: Auf dem Home-Bildschirm waren die App-Icons noch vorhanden, die eigentlichen Apps aber verschwunden, sodass die Icons leer waren und sich nicht starten ließen.
Weil ich mir Sorgen um die Datenintegrität machte, habe ich schließlich aus einem Backup wiederhergestellt.
Ich bin überzeugt, dass das eine Folge davon ist, dass APFS Copy-on-Write verwendet und Snapshots unterstützt.
Wenn Änderungen nicht sofort dauerhaft übernommen werden und frühere Versionen von Dateien in Snapshots erhalten bleiben, wird es problematisch, sobald nicht einmal mehr Platz für Snapshot-Metadaten vorhanden ist.
Bei knappem Speicher könnte man Snapshots überspringen, aber das Problem mit den CoW-Metadaten bleibt trotzdem.
Erstaunlich, dass man selbst 2024 mit all den intelligenten APFS-Volume-Management-Funktionen ein „versiegeltes“ Gerät wie ein iPhone allein dadurch in einen Zustand bringen kann, der eine DFU-Wiederherstellung erfordert, dass man den Benutzerspeicher vollschreibt.
Umgekehrt konnte ich bei einem Windows-11-Arbeitslaptop mit einem einzigen Daten-/Boot-Volume, dessen Speicher ich versehentlich komplett gefüllt hatte, weiterhin booten und das Problem bereinigen.
Vor Kurzem hatte ich eine ähnliche Situation auf der Systempartition einer Linux-Installation.
Die Partition war von Anfang an zu klein, und mit den angesammelten Updates blieb irgendwann kaum noch genug Platz, um überhaupt mit dem Löschen von etwas anzufangen.
Es dauerte ungefähr 30 Minuten, ein Unterverzeichnis zu finden, in dem ich auch nur ein kleines bisschen löschen konnte.
Es fühlte sich an, als wäre ich in einem Zimmer eingesperrt, das so voller Gerümpel war, dass sich die nach innen öffnende Tür nicht mehr öffnen ließ.
Von diesem kleinen Einstiegspunkt aus konnte ich nach und nach immer größere Bereiche löschen, und nachdem ich schließlich aufgeräumt hatte, vergrößerte ich die Partition, damit das nie wieder passiert.
Für erfahrene Nutzer sollte die Lehre wohl sein, hinter einer Partition immer etwas freien Speicherplatz zu lassen.