Was tun bei zu wenig Speicherplatz im Remote-Mac-CI? Diagnoseleitfaden 2026

Der Build bricht beim Schreiben ab, das Archiv lässt sich nicht sichern oder macOS meldet zu wenig Speicherplatz.

Schnellste sichere Maßnahme: Ermitteln Sie zuerst, ob DerivedData, Simulatoren, Archive oder der Runner-Arbeitsbereich den Speicher belegen. Löschen Sie nur Daten, deren Wiederherstellbarkeit Sie geprüft haben; entfernen Sie nicht pauschal den gesamten Entwicklerordner.

Für iOS- und macOS-Entwickler: Wenn Build oder Archivierung auf einem Remote-Mac scheitern, hilft Ihnen die Diagnose nach Verzeichnisart.
Für CI-Ingenieure: Wenn ein dauerhaft betriebener macOS-Runner zwischen Aufträgen Daten ansammelt, finden Sie hier eine sichere Bereinigungsstrategie.
Für kleine Betriebsteams: Wenn Sie zwischen Aufräumen, Workflow-Änderung und mehr Host-Kapazität entscheiden müssen, nutzen Sie die Prüf- und Abnahmeschritte.

Schritt 1: Fehlermeldung und Fehlerzeitpunkt auseinanderhalten

„Zu wenig Speicherplatz“ ist zunächst ein Symptom, keine Diagnose. Ein Build kann beim Schreiben temporärer Dateien scheitern, eine Archivierung beim Erzeugen oder Sichern des Archivs abbrechen und macOS gleichzeitig eine Warnung anzeigen. Diese Ereignisse können zusammenhängen, müssen aber nicht dieselbe Ursache haben.

Halten Sie vor jeder Änderung fest, in welchem Schritt der Fehler auftrat: Abhängigkeiten laden, kompilieren, testen, archivieren oder Artefakte übertragen. Notieren Sie außerdem das Arbeitsverzeichnis, den betroffenen Auftrag und die vollständige Fehlermeldung. Vergleichen Sie, ob es sich um einen einmaligen Ausfall handelt oder ob der freie Speicher nach mehreren Aufträgen stetig sinkt.

Für den ersten Überblick prüfen Sie den freien Platz des betroffenen Dateisystems, beispielsweise mit:

df -h /

Falls Arbeitsbereich oder temporäre Daten auf einem anderen Volume liegen, prüfen Sie auch dieses Volume. Ein freies Systemvolume sagt nichts darüber aus, ob ein separates Arbeitsvolume voll ist. Umgekehrt kann eine fehlgeschlagene Ausgabe auf ein Schreib- oder Berechtigungsproblem hindeuten, obwohl noch Speicher verfügbar ist. Deshalb gehören Dateisystem, Schreibziel und Runner-Protokoll gemeinsam zur Diagnose.

macOS zeigt Speicherbelegung auch in den Systemeinstellungen an. Diese Übersicht kann beim Einstieg helfen, ersetzt aber nicht die Prüfung der tatsächlich belegten Verzeichnisse. Apple beschreibt die verfügbaren Ansichten und Empfehlungen in der Anleitung zur Speicherprüfung auf dem Mac. Für CI-Fehler brauchen Sie zusätzlich den konkreten Pfad, in den der fehlgeschlagene Prozess schreiben wollte.

Schritt 2: Bei wiederkehrenden Warnungen die großen Verzeichnisse ermitteln

Wenn die Warnung nach einem Neustart oder nach dem Löschen einzelner Dateien zurückkehrt, suchen Sie nach dem Verzeichnis, dessen Inhalt tatsächlich wächst. Prüfen Sie nacheinander Entwicklerdaten, Arbeitsbereiche, Protokolle, heruntergeladene Komponenten und sonstige große Ordner. Systemkategorien sind nur ein Hinweis: Eine angezeigte Kategorie benennt nicht automatisch den sicheren Bereinigungskandidaten.

Für bekannte Pfade können Sie die Größe gezielt abfragen:

du -sh "$HOME/Library/Developer/Xcode/DerivedData"
du -sh "$HOME/Library/Developer/Xcode/Archives"

Ein fehlender Pfad ist nicht unbedingt ein Fehler. Xcode kann für ein Projekt einen abweichenden Speicherort verwenden; auch das Home-Verzeichnis des CI-Prozesses muss nicht Ihrem interaktiven Benutzerkonto entsprechen. Prüfen Sie deshalb, unter welchem Benutzer der Runner läuft und welche Pfade dessen Build-Konfiguration tatsächlich verwendet. Wenn du Zugriffsfehler meldet, sollten Sie diese nicht als „Ordner leer“ interpretieren. Die Berechtigungen können verhindern, dass der gesamte Inhalt erfasst wird.

Apple dokumentiert die Speicherorte und Funktionen von Xcode-generierten Daten. Die Xcode-Dokumentation zu Build-Dateien und Ablageorten ist hilfreich, um den erwarteten Standardpfad mit der konkreten Konfiguration abzugleichen. Entscheidend bleibt die Messung auf dem betroffenen Host: Ein bekannter Pfad ist kein Beweis dafür, dass dort auch die Ursache liegt.

Schritt 3: DerivedData und Archive getrennt beurteilen

Können Sie DerivedData im macOS-CI direkt löschen?

Nicht als pauschale Regel. DerivedData ist ein Sammelort für von Xcode erzeugte Projekt- und Build-Daten. Dazu können Zwischenstände, Indizes und Build-Ergebnisse gehören; Teile davon lassen sich bei Bedarf erneut erzeugen. Das bedeutet jedoch nicht, dass jedes Projekt denselben Speicherort verwendet oder dass das Entfernen während eines laufenden Auftrags folgenlos bleibt.

Prüfen Sie zunächst, ob noch ein Build oder Test auf diesen Daten arbeitet. Ermitteln Sie, welches Projekt betroffen ist und ob ein erneuter Build die benötigten Informationen wiederherstellen kann. Erst wenn keine laufende Aufgabe den Inhalt nutzt und Sie mit einem sauberen Neuaufbau rechnen können, kommt eine gezielte Bereinigung infrage. Bei einem CI-Auftrag mit knappem Zeitfenster kann das Löschen von wiederverwendbaren Build-Daten den nächsten Lauf verlängern oder einen erneuten Fehler durch eine unvollständige Bereinigung verdecken.

Archive sind davon getrennt zu behandeln. Sie sind nicht einfach ein weiterer Cache: Ein Archiv kann für Freigabe, spätere Untersuchung oder erneute Verarbeitung gebraucht werden. Prüfen Sie daher zuerst Aufbewahrungsregeln, Projektzuordnung und den Zweck der gespeicherten Archive. Apple behandelt Archivierungsprobleme gesondert in der technischen Anleitung zur Fehlerbehebung bei Xcode-Archiven. Löschen Sie ein Archiv nicht nur deshalb, weil es groß ist oder neben DerivedData liegt.

Achtung: Entfernen Sie keine laufend genutzten Verzeichnisse und keine Archive, bevor Aufbewahrungsbedarf und Wiederherstellbarkeit geklärt sind. Eine erfolgreiche Platzfreigabe ist kein Erfolg, wenn dadurch ein benötigtes Build-Ergebnis verloren geht.

Was tun, wenn der Xcode-Build auf dem Remote-Mac den Speicher vollschreibt?

Ordnen Sie den Zeitpunkt des Fehlers dem Schreibziel zu. Scheitert der Build bereits während der Kompilierung, prüfen Sie zuerst die verwendeten Build- und Zwischendaten. Tritt das Problem erst beim Archivieren oder Sichern auf, vergleichen Sie den Archivpfad, das Zielvolume und die dort vorhandene Belegung. Ein später Fehler im Workflow kann auch beim Kopieren oder Hochladen eines bereits erzeugten Artefakts entstehen.

Kontrollieren Sie die Build-Konfiguration, statt einen bekannten Standardpfad als gegeben anzunehmen. Xcode kann für ein Projekt einen anderen Ort für abgeleitete Daten verwenden. Das Ziel des Archivs ist ebenfalls anhand der konkreten Aufgabe zu prüfen. Apple erklärt in seiner Anleitung zum Erstellen und Ausführen einer App den Build-Ablauf; für die Diagnose müssen Sie diesen Ablauf mit dem letzten erfolgreichen Schritt in Ihrem CI-Protokoll abgleichen.

Ein belastbarer Befund verbindet drei Beobachtungen: den Fehlerzeitpunkt, den tatsächlich verwendeten Pfad und dessen Größe beziehungsweise freien Platz auf dem zuständigen Volume. Fehlt eine davon, ist eine umfassende Löschung kein Ersatz für die fehlende Information.

Schritt 4: Simulator-Komponenten und Gerätedaten einzeln prüfen

Simulator-bezogene Dateien sollten Sie nicht als einen einzigen Bestand behandeln. Unterscheiden Sie installierte iOS-Simulator-Laufzeitumgebungen, Daten einzelner virtueller Geräte und die Build-Ergebnisse des Projekts. Eine installierte Laufzeit kann für einen späteren Test gebraucht werden; Gerätedaten können den Zustand eines Tests enthalten; Build-Ergebnisse gehören zu einem anderen Teil der Pipeline.

Prüfen Sie in Xcode, welche Laufzeitumgebungen installiert sind und ob die aktuell verwendete Version sie benötigt. Apple beschreibt das Hinzufügen von Simulatoren in der Dokumentation zu zusätzlichen Simulatoren sowie die Installation weiterer Xcode-Komponenten in der Anleitung zu Xcode-Komponenten. Entfernen Sie keine Komponente, bevor Sie geprüft haben, ob ein laufender Test oder ein anderer Workflow darauf angewiesen ist.

Wenn Sie Simulator-Gerätedaten bereinigen, dokumentieren Sie vorher, welche Geräte betroffen sind und ob Testdaten daraus noch gebraucht werden. Vermeiden Sie das manuelle Löschen von Dateien aus systemverwalteten Simulator-Verzeichnissen, solange Sie deren Zweck nicht eindeutig festgestellt haben. Nutzen Sie die von Xcode angebotenen Verwaltungswege und kontrollieren Sie danach erneut, welcher Speicher freigegeben wurde. Ein Test, der nach der Bereinigung wieder startet, beweist noch nicht, dass Archivierung und nachfolgende Aufträge ebenfalls funktionieren.

Wie prüfen Sie nach dem Löschen von Simulator-Daten, ob der Build wieder funktioniert?

Führen Sie einen repräsentativen Auftrag mit dem betroffenen Projekt und der benötigten Simulator-Konfiguration aus. Vergewissern Sie sich, dass der Build schreibt, die Tests tatsächlich starten und die erwarteten Ergebnisse gespeichert werden. Danach prüfen Sie den freien Speicher und beobachten, ob der nächste Auftrag auf demselben Runner ebenfalls ausgeführt werden kann. Halten Sie fest, welche Daten Sie entfernt haben und wie sich der freie Platz vor und nach dem Lauf verändert hat. So sehen Sie, ob die Bereinigung die Ursache beseitigte oder lediglich Zeit bis zum nächsten Ausfall verschaffte.

Schritt 5: Auf einem selbst gehosteten Runner Aufgabenreste begrenzen

Bei einem selbst gehosteten macOS-Runner liegt die Verwaltung der persistenten Host-Daten bei Ihnen. Arbeitsverzeichnisse und wiederverwendete Caches können zwischen Aufträgen erhalten bleiben. Ob eine bestimmte Datei nach einem Auftrag gelöscht wird, hängt von Ihrer Runner-Konfiguration und dem Workflow ab. Die Dokumentation zu selbst gehosteten Runnern beschreibt diese Verwaltungsverantwortung; die Auswahl eines Runners für einen Auftrag unterscheidet außerdem selbst verwaltete Systeme von verwalteten Runnern.

Behandeln Sie Arbeitsbereich, Cache und Zugangsdaten getrennt. Ein Arbeitsbereich kann ausgecheckte Quellen und erzeugte Artefakte enthalten. Ein Cache kann bewusst für spätere Aufträge vorgesehen sein. Ein Verzeichnis mit Zugangsdaten ist dagegen sicherheitskritisch und darf nicht als gewöhnlicher Bereinigungskandidat behandelt werden. Löschen Sie nicht alle drei Bereiche mit demselben Skript und denselben Regeln.

Legen Sie eine Bereinigung nach dem Auftrag oder vor dem nächsten Auftrag nur für klar definierte, entbehrliche Inhalte fest. Protokollieren Sie Belegung und freien Speicher vor und nach relevanten Jobs. Wenn Sie Container oder isolierte Arbeitsumgebungen einsetzen, prüfen Sie zusätzlich deren persistente Ablage und Bereinigungsregeln; die Anleitung zum Anpassen von Runner-Containern erläutert die zugehörige Runner-Konfiguration. Ein Container allein garantiert nicht, dass alle Host-Daten verschwinden.

Schritt 6: Bereinigung mit einem kontrollierten Auftrag abnehmen

Nutzen Sie diese Liste vor und nach der Änderung. Wenn ein Punkt nicht geklärt ist, halten Sie die Bereinigung an und ermitteln Sie zuerst die fehlende Information.

• [ ] Fehlerphase, vollständige Meldung, Arbeitsverzeichnis und ausführender Benutzer sind dokumentiert.
• [ ] Freier Speicher wurde auf dem Volume geprüft, auf das der fehlgeschlagene Prozess schreibt.
• [ ] Die Größe der verdächtigen Verzeichnisse wurde unter den Berechtigungen des tatsächlichen Runner-Kontos ermittelt.
• [ ] DerivedData, Archive, Simulator-Laufzeitumgebungen, Gerätedaten und Arbeitsbereiche wurden getrennt bewertet.
• [ ] Aufbewahrungsbedarf und Wiederherstellbarkeit wurden geklärt, bevor Inhalte entfernt wurden.
• [ ] Es wird kein laufender Auftrag durch die Bereinigung beeinflusst.
• [ ] Ein repräsentativer Build, Test oder Archivierungslauf wurde nach der Änderung ausgeführt.
• [ ] Artefakte und Protokolle wurden am erwarteten Ort gespeichert und sind im nächsten Auftrag erreichbar.
• [ ] Freier Speicher wurde erneut geprüft; bei einem selbst gehosteten Runner ist auch die Entwicklung über weitere Aufträge dokumentiert.

Wo sollte die nächste Maßnahme ansetzen?

Schritt 7: Zwischen Bereinigung, Workflow-Änderung und Host-Kapazität entscheiden

Eine einmalige Bereinigung ist passend, wenn Sie entbehrliche Daten eindeutig identifiziert haben und der Fehler danach nicht erneut auftritt. Wenn dieselben Verzeichnisse nach jedem Auftrag wieder wachsen, ändern Sie die Aufbewahrung oder den Workflow, statt regelmäßig blind zu löschen. Wenn die benötigten Daten selbst bei sinnvoller Aufbewahrung den verfügbaren Platz überfordern, ist die Host-Kapazität neu zu bewerten.

Der Wechsel zu einem Remote-Mac löst nicht automatisch eine falsche Cache- oder Aufbewahrungsstrategie. Er kann jedoch sinnvoll sein, wenn Ihre aktuelle Lösung macOS-Werkzeuge nicht bereitstellt, eine lokale Maschine nur zeitweise erreichbar ist oder das Team keinen eigenen Mac als dauerhaft verfügbaren Runner betreiben möchte. Ein eigener Mac eignet sich eher, wenn die Last langfristig stabil und hoch ist oder physische Anschlüsse benötigt werden. Bei wechselndem Bedarf können Sie stattdessen eine gemietete Mac-Umgebung prüfen; MangoVM bietet den Zugriff auf eine echte Mac-Umgebung per VNC, SSH oder Webkonsole und mit Root-Rechten. Details zu den verfügbaren Möglichkeiten finden Sie auf der MangoVM-Übersichtsseite.

Bevor Sie umstellen, planen Sie auch Zugriffsrechte, Geheimnisse und Protokollaufbewahrung. Übertragen Sie keine Zugangsdaten in allgemein lesbare Arbeitsverzeichnisse. Prüfen Sie, welche Teammitglieder Zugriff benötigen und wie sensible Build-Daten geschützt werden; Hinweise zu den Rahmenbedingungen finden Sie in den Datenschutzinformationen. Für dauerhafte, gut planbare Auslastung kann ein eigener Mac wirtschaftlicher und einfacher zu kontrollieren sein. Für einen zeitlich begrenzten Test, einen zusätzlichen CI-Knoten oder eine vorübergehende Build-Spitze ist Miete oft flexibler als ein Hardwarekauf. Wenn die aktuelle Umgebung an falscher Bereinigung, fehlender Überwachung oder ungeeigneter Workflow-Konfiguration scheitert, beheben Sie zuerst diese Ursache. Wenn Sie dagegen nachweisen, dass die Last dauerhaft die vorhandene Host-Kapazität übersteigt, vergleichen Sie eine passende Remote-Mac-Umgebung mit dem Betrieb eigener Hardware.