Mac-Speicher voll, obwohl nichts drauf ist? Prüfen Sie den Log-Ordner von Root

Hier ist ein Speicherproblem, an dem so gut wie jedes Tool scheitert, zu dem die meisten Menschen als Erstes greifen.

Ihr Mac meldet, dass die Festplatte fast voll ist. Sie öffnen ein Speicher-Analyse-Tool und addieren, was es findet – und die Summe liegt um zig Gigabyte unter dem, was macOS als belegt ausweist. Disk Utility meldet keine Snapshots. Sie löschen Apps, lagern Fotos aus, leeren den Papierkorb, und die Zahl bewegt sich kaum. Ein Neustart hilft für eine Stunde, dann verschwindet der Speicherplatz wieder.

Die Dateien sind real. Ihre Tools können sie nicht sehen, weil sie sich in /private/var/root befinden – dem Home-Verzeichnis des Root-Kontos – und jedes dieser Tools läuft unter Ihrem eigenen Benutzerkonto.

Auf den Macs, bei denen es am härtesten zuschlägt, ist der Großteil davon eine einzige Sache: Log-Dateien, die von einem Systemdienst namens rtcreportingd geschrieben werden, und zwar in Größenordnungen von zig Gigabyte. Michael Tsai dokumentierte am 21. August 2026 einen Fall, bei dem allein /private/var/root/Library/Logs 74 GB auf einem M4 MacBook Air belegte – und bei dem der Ordner innerhalb eines einzigen Tages nach dem Leeren wieder auf 27 GB anwuchs.

Die Logs sind nicht die Krankheit. Sie sind das, was ein festgefahrener Daemon anrichtet, wenn niemand aufs Thermometer schaut. Dieser Artikel zeigt, wie Sie den Speicherplatz finden, wie Sie ihn zurückgewinnen, ohne den klassischen Fehler zu begehen, der die ganze Übung zunichtemacht, und wie Sie den Prozess finden, der ihn tatsächlich erzeugt.

Wichtigste Erkenntnisse

• /private/var/root ist für alles unsichtbar, was unter Ihrem Benutzerkonto läuft. Wir haben unter macOS 26.5.2 bestätigt, dass ls /private/var/root mit Permission denied quittiert wird. Speicher-Analyse-Tools, Finder und die Nutzungsangaben von Disk Utility übersehen allesamt, was sich darin befindet.
• rtcreportingd ist ein echter Apple-Systemdienst, der als Root läuft. Wir haben verifiziert, dass sein launchd-Job UserName => root deklariert – genau deshalb landen seine Logs im Home-Verzeichnis von Root und nicht in Ihrem.
• Die gemeldeten Größen erreichen zig Gigabyte und wachsen schnell nach. 74 GB in einem dokumentierten Fall, innerhalb eines Tages nach dem Löschen wieder auf 27 GB, weil die zugrunde liegende Ursache weiterlief.
• Der klassische Fehler macht die ganze Arbeit zunichte. Wenn Sie Dateien mit einem GUI-Tool löschen, das unter sudo läuft, wandern sie in Roots unsichtbaren Papierkorb. Der Speicherplatz wird nicht freigegeben. Sie müssen entweder sofort endgültig löschen oder Roots Papierkorb leeren.
• Suchen Sie nach einem hängengebliebenen Sync-Client. Im dokumentierten Fall lagen rtcreportingd und fileproviderd beide nahe 100 % CPU-Auslastung, und das Beenden von Dropbox stoppte beide. fileproviderd ist der macOS-Prozess, der Cloud-Speicher-File-Provider-Erweiterungen hostet.
• Löschen Sie nicht wahllos Dinge in /private/var/root. Logs und Caches können gefahrlos entfernt werden. Anderes dort nicht – dieser Artikel benennt genau, was was ist.

Warum Ihre Speicher-Tools Es Nicht Sehen Können

Vor der Lösung erst der Mechanismus – denn wer ihn versteht, jagt beim nächsten Mal nicht wieder dem Falschen hinterher.

Root Hat Ein Home-Verzeichnis, Und Daemons Nutzen Es

Unter macOS ist /private/var/root das Home-Verzeichnis des Root-Kontos. Die meisten Menschen nehmen an, es sei im Grunde leer und werde nur berührt, wenn man Terminal aus der macOS-Wiederherstellung heraus startet. Das stimmt seit Jahren nicht mehr. Systemdienste, die als Root laufen und Zustand, Caches oder Logs speichern wollen, schreiben sie dorthin – im selben Library-Layout, das auch Ihr eigenes Home-Verzeichnis verwendet:

/private/var/root/Library/Logs
/private/var/root/Library/Caches

Mit einem einzigen Befehl können Sie bestätigen, dass Ihnen der Zugriff auf das Verzeichnis verwehrt ist. Auf einem Mac, auf dem Terminal keine erhöhten Rechte besitzt:

ls /private/var/root

Wir haben genau das unter macOS 26.5.2 (Build 25F84) ausgeführt und Folgendes erhalten:

ls: /private/var/root: Permission denied

Das ist eine ganz gewöhnliche Unix-Rechteverweigerung – Roots Home-Verzeichnis ist per Dateimodus auf Root beschränkt. Es handelt sich nicht um einen TCC-Datenschutzschutz, und Vollzugriff auf die Festplatte (Full Disk Access) behebt das nicht. Ein Speicher-Analyse-Tool, das Sie aus dem Dock starten, läuft unter Ihrem Konto, durchsucht das Dateisystem also auch als Sie – und alles unterhalb dieses Verzeichnisses ist ein Loch in seiner Landkarte.

Deshalb Stimmen Die Zahlen Nicht Überein

Das Symptom, das Menschen beschreiben, lautet: „Die Summen meines Speicher-Tools passen nicht zusammen" – und das ist der Grund. Im dokumentierten Fall lagen die Ordnersummen von OmniDiskSweeper um rund 90 GB niedriger als das, was macOS als belegt meldete.

Es lohnt sich, das von den anderen Gründen zu trennen, aus denen die Angaben zum freien Speicherplatz auf dem Mac auseinanderklaffen – es gibt mehrere davon, und nur einer ist dieser Bug.

Howard Oakley legte am 21. August 2026 die allgemeine Rechnung dar, und die Zahlen von seinem eigenen Mac mini verdeutlichen den Punkt:

Quelle	Als belegt gemeldet auf demselben Volume
Container-Differenz von diskutil apfs list	837.101 GB
Summe der Capacity Consumed pro Volume	837.027 GB
„Informationen" zum Volume im Finder	826.67 GB
Disk Utility	814.03 GB

Vier Tools, vier Zahlen, eine Spannweite von etwa 23 GB – und nichts ist falsch. Die Unterschiede stammen aus der Container-versus-Volume-Buchführung, aus purgeable Space und aus dem Verhalten von APFS-Spezialdateien:

• Container versus Volume. Ein APFS-Container enthält mehrere Volumes, die sich den freien Speicherplatz teilen. „Freier Speicherplatz auf Macintosh HD" und „freier Speicherplatz im Container" sind unterschiedliche Fragen mit unterschiedlichen Antworten.
• Purgeable Space. macOS markiert manche Inhalte als bei Bedarf entfernbar – Caches, manche Snapshots, manche heruntergeladenen Inhalte. Im Hilfe-Handbuch von Disk Utility heißt es dazu: „Als purgeable gekennzeichnete Dateien können Sie nicht manuell entfernen, aber macOS entfernt sie, sobald Speicherplatz benötigt wird." Oakley maß 47.04 GB purgeable Space auf seinem Data-Volume.
• Spezialdateien. APFS-Clone-Dateien teilen sich Speicherplatz, bis sie divergieren; Sparse-Dateien speichern nur ihre Nicht-Null-Daten; manche Systemdateien sind komprimiert; dataless Files halten ihre Daten in der Cloud vor und materialisieren sie bei Bedarf. Die Berechnung des freien Speicherplatzes berücksichtigt, was jetzt auf der Festplatte liegt.

Nichts davon erzeugt eine dauerhafte, wachsende, unerklärliche Lücke von 90 GB. Wenn Ihre Lücke klein und stabil ist, ist das normale Buchführung. Wenn sie groß ist und wächst, während der Mac im Leerlauf ist, schreibt etwas Dateien, die Sie nicht sehen können.

Für die häufigeren Speicherverwirrungen – System Data, die nicht schrumpft, Snapshots, die nicht freigegeben werden – behandeln wir das separat in System Data storage huge on Mac und im macOS storage management guide. Prüfen Sie diese zuerst. Dieser Artikel behandelt den Fall, in dem jene Erklärungen nicht passen.

Was rtcreportingd Tatsächlich Ist

Seien wir ehrlich über die Grenzen dessen, was wir wissen, denn das Internet wird sich bald mit selbstbewussten Erklärungen zu einem Daemon füllen, den Apple nie dokumentiert hat.

Was wir direkt verifiziert haben, unter macOS 26.5.2 (Build 25F84):

Die ausführbare Datei liegt unter /usr/libexec/rtcreportingd und ist etwa 1,45 MB groß. Ihr launchd-Job befindet sich unter /System/Library/LaunchDaemons/com.apple.rtcreportingd.plist und lautet:

{
  "EnablePressuredExit" => true
  "EnableTransactions" => true
  "Label" => "com.apple.rtcreportingd"
  "MachServices" => {
    "com.apple.rtcreportingd" => true
  }
  "ProgramArguments" => [
    0 => "/usr/libexec/rtcreportingd"
  ]
  "UserName" => "root"
}

Prüfen Sie es auf Ihrem eigenen Mac – die plist ist für alle lesbar:

plutil -p /System/Library/LaunchDaemons/com.apple.rtcreportingd.plist

UserName => root ist die vollständige Erklärung dafür, wohin die Logs gehen. Ein Daemon, der als Root läuft und nach ~/Library/Logs schreibt, schreibt nach /private/var/root/Library/Logs. Daran ist nichts Exotisches.

Das Binary ist in Swift geschrieben, und seine internen Klassennamen sind mit strings sichtbar. Dazu zählen BackendHTTP, TransparencyLog, StorebagCache, StorebagCoordinator, SessionCoordinator, XPCActivity und – das ist bemerkenswert – CacheCleanupActivity. Zu seinen Mach-Service-Namen gehören com.apple.rtcreporting, com.apple.rtcreporting.pathmonitor und com.apple.rtcreportingd.storebag.

Was wir Ihnen nicht sagen werden, ist, wofür „RTC" steht oder worüber der Daemon genau berichtet. Apple dokumentiert es nicht, und wir werden uns keine Auflösung dieser Abkürzung ausdenken und als Tatsache präsentieren. Was die Klassennamen stützen, ist eine bescheidene Beschreibung: Es handelt sich um einen Reporting- oder Telemetriedienst, der über HTTP mit einem Apple-Backend kommuniziert, Zustand lokal cacht, die Verfügbarkeit von Netzwerkpfaden überwacht und über eine geplante Aktivität zum Aufräumen seines eigenen Caches verfügt.

Dieses letzte Detail ist das interessante. Der Daemon verfügt über eine Aufräumlogik. Wenn seine Logs auf zig Gigabyte anwachsen, lautet die vernünftige Lesart nicht „Apple hat vergessen, die Logs zu rotieren", sondern „etwas erzeugt Ereignisse schneller, als der Daemon sie verarbeiten und danach aufräumen kann". Das verweist auf das, was die Ereignisse erzeugt.

Um die Grenze klarzumachen: Das ist eine Schlussfolgerung aus Klassennamen, keine Aussage über Apples Implementierung. Betrachten Sie es als Hypothese, die zufällig zum beobachteten Verhalten passt.

Den Speicherplatz Finden

Für all das benötigen Sie sudo, und Sie sollten jeden Befehl lesen, bevor Sie ihn ausführen.

1. Bestätigen, Dass Die Lücke Existiert

Zunächst: was macOS als belegt betrachtet:

df -h / /System/Volumes/Data

Auf einem modernen Mac erhalten Sie zwei Zeilen, weil das Systemvolume ein versiegelter, schreibgeschützter Snapshot ist und Ihre Daten auf einem separaten Volume im selben Container liegen. Auf unserem Test-Mac:

Filesystem        Size    Used   Avail Capacity  Mounted on
/dev/disk3s1s1   926Gi    12Gi   331Gi     4%    /
/dev/disk3s5     926Gi   568Gi   331Gi    64%    /System/Volumes/Data

Beachten Sie, dass beide dieselbe Size und Avail melden – das ist der gemeinsam genutzte freie Speicherplatz des Containers, keine Quote pro Volume. Das ist die zuvor beschriebene Unterscheidung zwischen Container und Volume, hier konkret.

Prüfen Sie anschließend die Snapshots, um sie ausschließen zu können:

diskutil apfs listSnapshots /System/Volumes/Data

Und die Container-Ansicht:

diskutil apfs list

Wenn die Snapshots minimal sind und die Capacity In Use des Containers weit über dem liegt, was Ihr Speicher-Analyse-Tool gefunden hat, haben Sie ein Problem mit unsichtbaren Dateien.

2. Roots Home-Verzeichnis Messen

Das ist der Befehl, der es findet:

sudo du -h -d 2 /private/var/root/

-d 2 begrenzt die Tiefe auf zwei Ebenen – genug, um zu sehen, ob Library/Logs oder Library/Caches der Übeltäter ist, ohne auf einen vollständigen Durchlauf zu warten. Rechnen Sie auf einer Maschine mit einem großen Übeltäter mit ein bis zwei Minuten.

Für eine sortierte Ansicht der schlimmsten Übeltäter eine Ebene tiefer:

sudo du -h -d 3 /private/var/root/Library | sort -h | tail -20

Auf einem gesunden Mac sind diese Summen klein – Megabyte, keine Gigabyte. Wenn /private/var/root/Library/Logs mit einer Zahl zurückkommt, der ein „G" folgt und die mehr als eine Ziffer davor hat, ist das Ihr fehlender Speicherplatz.

3. Nachsehen, Was Drin Ist

Bevor Sie irgendetwas löschen, schauen Sie nach:

sudo ls -la /private/var/root/Library/Logs
sudo du -h -d 1 /private/var/root/Library/Logs | sort -h | tail

Im dokumentierten Fall stammte der Inhalt „fast vollständig von RTCReporting". Wenn bei Ihnen etwas anderes dominiert, ändert das, was Sie tun sollten – der diagnostische Ansatz dieses Artikels gilt weiterhin, aber der Übeltäter ist ein anderes Subsystem.

4. Eine GUI-Alternative

Wenn Sie das lieber in einem Fenster sehen möchten: OmniDiskSweeper ist kostenlos und war das Tool, das das Problem im ursprünglichen Bericht ans Licht brachte. Wichtig ist: Sie müssen es mit erhöhten Rechten neu starten, damit es Roots Home-Verzeichnis sehen kann. Normal gestartet zeigt es Ihnen dasselbe unvollständige Bild wie alle anderen Tools.

Unser Überblick über Speicher-Analyse-Tools behandelt die Optionen, aber beachten Sie, dass für alle dieselbe Einschränkung gilt: Läuft das Tool nicht als Root, ist dieser Speicherplatz für es unsichtbar.

Speicherplatz Zurückgewinnen — Und Der Fehler, Der Die Ganze Arbeit Zunichtemacht

Hier ist die Falle, und es ist eine gute.

Wenn Sie diese Dateien mit einem GUI-Tool löschen, das unter sudo läuft, tut das Tool das, was es immer tut: Es verschiebt sie in den Papierkorb. Aber weil der Prozess als Root läuft, ist das Roots Papierkorb, unter /private/var/root/.Trash – der nicht in Ihrem Dock erscheint und an dessen Leerung Sie nie denken werden. Die Dateien liegen weiterhin auf der Festplatte. Ihr freier Speicherplatz ändert sich nicht. Sie schließen daraus, dass das Löschen nicht funktioniert hat.

In OmniDiskSweeper konkret: Halten Sie Option gedrückt, um aus Delete ein Delete Immediately zu machen.

Löschen Sie den Inhalt der Logs direkt über Terminal:

sudo rm -rf /private/var/root/Library/Logs/*

Lesen Sie diesen Befehl, bevor Sie ihn ausführen. Er entfernt den Inhalt von Roots Logs-Verzeichnis und nichts sonst. Kürzen Sie den Pfad nicht. Fügen Sie kein Leerzeichen vor dem Schrägstrich ein.

Prüfen Sie anschließend, ob sich aus einem früheren Versuch noch etwas in Roots Papierkorb befindet:

sudo du -sh /private/var/root/.Trash

Und falls ja:

sudo rm -rf /private/var/root/.Trash/*

Auch Caches in Roots Home-Verzeichnis lassen sich in der Regel gefahrlos leeren – sie sind per Definition regenerierbar:

sudo du -h -d 1 /private/var/root/Library/Caches | sort -h | tail

Was Sie nicht anfassen sollten. Löschen Sie nicht /private/var/root selbst. Löschen Sie nicht /private/var/root/Library als Ganzes. Entfernen Sie keine Schlüsselbunde, Einstellungen oder irgendetwas, das Sie nicht erkennen. Logs und Caches sind die sicheren Kategorien; alles andere dort gehört einer Systemkomponente, die es aus einem bestimmten Grund dort abgelegt hat.

Starten Sie den Mac danach neu. Prüfen Sie anschließend erneut mit df -h, ob der Speicherplatz tatsächlich zurückgekommen ist.

Jetzt Die Ursache Finden

Wenn Sie es beim Löschen belassen, kommt der Speicherplatz zurück und verschwindet dann wieder. Im dokumentierten Fall waren es innerhalb weniger Minuten nach dem Neustart wieder 5 GB und innerhalb eines Tages 27 GB.

Die CPU Beobachten

Öffnen Sie Activity Monitor, sortieren Sie nach % CPU und achten Sie auf zwei Prozesse:

• rtcreportingd – der Daemon, der die Logs schreibt
• fileproviderd – der macOS-Prozess, der Cloud-Speicher-File-Provider-Erweiterungen hostet

Im dokumentierten Fall lagen beide durchgehend nahe 100 % CPU-Auslastung, auf einem im Leerlauf befindlichen Mac.

Über Terminal:

ps -Ao pid,pcpu,comm | grep -E 'rtcreportingd|fileproviderd'

Beide Prozesse existieren und laufen auf jedem gesunden Mac – wir haben beide auf unserer Testmaschine bestätigt, die überhaupt kein Speicherproblem hat. Ihre Anwesenheit ist normal. Ihre anhaltende CPU-Nutzung nicht. Ein paar Prozent während eines laufenden Syncs sind zu erwarten. Bei 90–100 % zu verharren, während der Mac unberührt bleibt, ist das Signal.

Das Wachstum Der Logs Beobachten

Die direkteste Bestätigung erhalten Sie durch zweimaliges Messen:

sudo du -sh /private/var/root/Library/Logs

Warten Sie zehn Minuten bei im Leerlauf befindlichem Mac und führen Sie es erneut aus. Auf einem gesunden Mac bewegt sich die Zahl nicht nennenswert. Steigt sie messbar, während Sie nichts tun, steckt etwas in einer Schleife.

Zuerst Cloud-Sync Verdächtigen

fileproviderd ist der Verräter. Es ist der Systemprozess, der File-Provider-Erweiterungen hostet – der moderne Mechanismus, mit dem Dropbox, OneDrive, Google Drive, Box und iCloud Drive Cloud-Dateien im Finder darstellen. Verbrennt er durchgehend CPU, hängt eine dieser Erweiterungen fest.

Im dokumentierten Fall war der Client Dropbox, auf einem Mac, auf dem er sich seit etwa einem Jahr fehlerhaft verhalten hatte – Dateien wurden nicht wie konfiguriert offline gehalten, und es sah so aus, als würde ständig synchronisiert, obwohl sich nichts geändert hatte. Das Beenden von Dropbox stoppte sowohl die CPU-Nutzung als auch das Wachstum der Logs sofort.

Um das auf Ihrem eigenen Mac zu testen, beenden Sie Ihre Sync-Clients einzeln nacheinander und beobachten Sie. Beenden Sie den Client vollständig – Menüleisten-Symbol, Quit – statt nur die Synchronisierung zu pausieren, denn eine pausierte Erweiterung kann weiterhin geladen sein.

# after quitting a sync client, check whether the load dropped
ps -Ao pid,pcpu,comm | grep -E 'rtcreportingd|fileproviderd'

Wenn das Beenden eines Clients beide Prozesse in den Leerlauf versetzt, haben Sie es gefunden.

Was Mit Dem Sync-Client Zu Tun Ist

Optionen, grob nach Aufwand geordnet:

1. Aktualisieren. Bugs in File-Provider-Erweiterungen sind häufig und werden oft behoben. Prüfen Sie zuerst auf ein Update.
2. Ab- und wieder anmelden. Das baut den lokalen Zustand der Erweiterung neu auf und löst eine überraschende Zahl hängender Sync-Fälle.
3. Client entfernen und neu installieren. Störender, aber gründlicher.
4. Die Daten woanders hin verschieben. Im dokumentierten Fall war das Ergebnis eine Migration zu iCloud Drive, nachdem sich Dropbox als unfähig erwiesen hatte, Dateien für den Umzug zuverlässig herunterzuladen – der Autor lud den Ordner stattdessen über die Web-Oberfläche von Dropbox herunter. iCloud Drive „lud daraufhin alles zügig hoch und ging anschließend in einen Zustand ohne CPU-Nutzung über".

Dieser letzte Punkt verdient ehrliche Erwähnung: Die Migration zwischen Cloud-Anbietern, wenn der Quell-Client defekt ist, ist wirklich mühsam, und die Web-Oberfläche ist womöglich Ihr zuverlässigster Exportweg. Unser iCloud Drive Guide behandelt die Zielseite, und falls iCloud Drive selbst Probleme macht, ist der iCloud-Drive-Auto-Download-Bug ein bekanntes, separates Problem.

Wir behaupten nicht, dass die Schuld allein bei Dropbox liegt. Es ist der Client im dokumentierten Fall. Jede File-Provider-Erweiterung kann hängenbleiben, und die Diagnose ist dieselbe, egal welche Sie verwenden.

Die Anderen Orte, An Denen Sich Speicherplatz Vor Ihnen Versteckt

Roots Home-Verzeichnis ist der Ort, den fast niemand prüft, aber es ist nicht der einzige Ort, an dem ein Tool auf Benutzerebene versagt. Wenn Ihre Lücke nicht in /private/var/root liegt, arbeiten Sie Folgendes durch, bevor Sie schließen, dass die Zahlen lügen.

Root-eigene Daten anderer Daemons. /private/var/root ist der Ort, an dem Roots Home-Verzeichnis liegt, aber Systemkomponenten schreiben auch unter /private/var/db, /private/var/folders und /Library/Logs. Messen Sie sie auf dieselbe Weise:

sudo du -h -d 1 /private/var/db | sort -h | tail
sudo du -h -d 1 /Library/Logs | sort -h | tail
sudo du -sh /private/var/folders

/private/var/folders enthält temporäre Container und Cache-Container pro Benutzer und kann legitimerweise mehrere Gigabyte erreichen. Es wird von macOS verwaltet und sollte generell in Ruhe gelassen werden; ein Neustart räumt die flüchtigen Teile weg.

Lokale Time-Machine-Snapshots. Das ist die am häufigsten beschuldigte und am seltensten tatsächlich schuldige Ursache. Prüfen Sie, statt zu vermuten:

tmutil listlocalsnapshots /
diskutil apfs listSnapshots /System/Volumes/Data

Falls Snapshots tatsächlich das Problem sind, dünnt macOS sie unter Speicherdruck automatisch aus, und die tiefergehenden Fälle behandeln wir in unserem Time-Machine-Troubleshooting-Guide.

Home-Verzeichnisse anderer Benutzer. Einmal ausgesprochen offensichtlich, in der Praxis unsichtbar – ein zweites Konto auf dem Mac mit 200 GB Video zeigt Ihnen Ihr Speicher-Tool nicht, solange es unter Ihrem Konto läuft. sudo du -h -d 1 /Users beantwortet das in einer Zeile.

Von einem laufenden Prozess offengehaltene Dateien. Speicherplatz, der gelöscht, aber nicht freigegeben wurde, weil ein Prozess noch den Dateideskriptor hält. Das zeigt sich als Lücke, die nach einem Neustart verschwindet:

sudo lsof / 2>/dev/null | grep -i deleted | head

Mails lokaler Speicher, iOS-Gerätebackups und Xcode. Die drei klassischen großen und vergessenen Verzeichnisse auf dem Mac eines Entwicklers oder eines intensiven Mail-Nutzers:

du -sh ~/Library/Mail
du -sh ~/Library/Application\ Support/MobileSync/Backup
du -sh ~/Library/Developer/Xcode/{DerivedData,iOS\ DeviceSupport,Archives} 2>/dev/null

All das ist unter Ihrem eigenen Benutzerkonto lesbar, ein Speicher-Analyse-Tool findet es also – es geht nur in einer langen Liste unter. Einen Blick wert, bevor Sie zu sudo eskalieren.

Materialisierte Cloud-Platzhalterdateien. Wenn Sie in irgendeinem Sync-Client eine Einstellung wie „Dateien nur online halten" nutzen, kann ein Bug oder eine Volltextsuche im Stillen alles herunterladen. Das ist dieselbe Fehlerklasse wie in diesem Artikel und zeigt sich meist als stetiges Wachstum im Sync-Ordner selbst.

Wie Häufig Ist Das?

Ehrliche Antwort: Wir wissen es nicht, und niemand sonst, der darüber publiziert, weiß es.

Was öffentlich dokumentiert ist: ein Erfahrungsbericht aus erster Hand mit konkreten Zahlen und einer konkreten Lösung, ein Thread in der Apple Support Community zum RTCReporting-Speicherverbrauch und ein Reddit-Thread von Nutzern, die fragen, was ihren Speicherplatz belegt. Das reicht, um zu belegen, dass das Problem real und reproduzierbar ist – aber nicht, um zu sagen, welcher Anteil der Macs betroffen ist.

Was wir aus eigener Prüfung sagen können: rtcreportingd läuft auf einem unveränderten Mac ohne Speicherproblem, seine Logs sind dort unauffällig, und der Daemon verfügt über eine Aufräumlogik, die offenbar meistens funktioniert. Das ist ein Fehlermodus, kein Standardverhalten. Wenn die Speicherangaben Ihres Macs zusammenpassen, gibt es nichts zu reparieren.

Apple hat kein Support-Dokument dazu veröffentlicht, das Problem nicht anerkannt und keine dokumentierte Lösung ausgeliefert. Wenn es Sie trifft, sind die fünf Minuten für ein Feedback an Apple gut investiert – ein nicht anerkanntes Problem bleibt unanerkannt.

Häufige Probleme Beheben

sudo du Braucht Ewig

Das ist normal bei einem großen oder stark fragmentierten Verzeichnisbaum. Verwenden Sie zuerst -d 1, um herauszufinden, welcher übergeordnete Ordner groß ist, und steigen Sie dann nur in diesen hinab. Vermeiden Sie es, du über die gesamte Festplatte laufen zu lassen, wenn Sie bereits wissen, welches Verzeichnis Sie interessiert.

Ich Habe Die Logs Gelöscht, Aber Der Freie Speicherplatz Hat Sich Nicht Geändert

Das Papierkorb-Problem. Prüfen Sie mit sudo du -sh /private/var/root/.Trash und leeren Sie ihn mit sudo rm -rf /private/var/root/.Trash/*. Das erwischt fast jeden, der ein GUI-Tool verwendet hat.

Die zweite Möglichkeit ist, dass ein Prozess die gelöschten Dateien noch offen hält – dann wird der Speicherplatz erst freigegeben, wenn der Prozess beendet wird. Starten Sie den Mac neu und prüfen Sie erneut.

Der Speicherplatz War Innerhalb Eines Tages Wieder Weg

Zu erwarten, wenn Sie die Ursache noch nicht gefunden haben. Das Löschen der Logs behandelt nur das Symptom. Gehen Sie zum Activity-Monitor-Schritt und finden Sie heraus, was in einer Schleife steckt.

rtcreportingd Nutzt CPU, Aber Ich Habe Keine Cloud-Sync-Clients

Dann liegt der Auslöser woanders. Sortieren Sie Activity Monitor nach CPU und schauen Sie, was sonst beschäftigt ist. Prüfen Sie das Unified Log auf die eigene Aktivität des Daemons:

log show --predicate 'process == "rtcreportingd"' --last 1h --info | head -50

Beachten Sie, dass Unified-Log-Abfragen nur zurückgeben, was tatsächlich geschrieben wurde, und Log-Daten laufen mit der Zeit ab – eine Abfrage über ein langes Zeitfenster kann durchaus nichts liefern.

Disk Utility Erste Hilfe Sagt, Die Festplatte Sei In Ordnung

Das wird sie auch. Das ist keine Dateisystembeschädigung. Erste Hilfe prüft die Konsistenz der Metadaten; ein Verzeichnis voller großer, gültiger Dateien ist vollkommen konsistent.

Kann Ich rtcreportingd Einfach Deaktivieren?

Wir würden es nicht tun. Es ist ein Apple-Systemdienst auf einem Mac mit System Integrity Protection, und das Deaktivieren von System-Launch-Daemons, um ein Symptom zu umgehen, erzeugt später tendenziell ein zweites, weniger offensichtliches Problem. Beheben Sie stattdessen den Prozess, der es antreibt. Verhält sich der Daemon ohne erkennbaren Auslöser fehlerhaft, ist das ein Apple-Bug, den man melden sollte, statt ihn zu umgehen.

Meinem Mac Geht Der Speicherplatz Aus, Und Ich Brauche Jetzt Platz

Sofortige, gefahrlose Erfolge während der Diagnose: Ihren eigenen Papierkorb leeren, Roots Papierkorb wie oben leeren, den Inhalt der Root-Logs löschen und sudo du -h -d 1 /private/var/root/Library/Caches prüfen. Zusammen geben diese Schritte oft genug frei, um den Mac wieder nutzbar zu machen, während Sie die Ursache suchen. Unser Guide zu Update-Fehlern durch unzureichenden Speicherplatz behandelt, was zu tun ist, wenn dies konkret ein macOS-Update blockiert.

FAQ

Was Ist /private/var/root?

Es ist das Home-Verzeichnis des Root-Kontos unter macOS. Es ist nur für Root lesbar, weshalb Tools, die unter Ihrem Benutzerkonto laufen, nicht hineinsehen können. Systemdienste, die als Root laufen, speichern dort Logs, Caches und Zustand, mit derselben Library-Struktur wie Ihr eigenes Home-Verzeichnis.

Warum Können Finder Oder Meine Speicher-App Diese Dateien Nicht Sehen?

Weil sie unter Ihrem Konto laufen und die Unix-Rechte des Verzeichnisses Ihren Benutzer ausschließen. Das ist kein Datenschutzschutz, den Vollzugriff auf die Festplatte aufheben könnte – es sind ganz gewöhnliche Dateirechte. Ein GUI-Tool muss mit erhöhten Rechten neu gestartet werden, um dieses Verzeichnis zu durchsuchen.

Was Ist rtcreportingd?

Ein Apple-Systemdienst unter /usr/libexec/rtcreportingd, gestartet von com.apple.rtcreportingd und laufend als Root. Apple dokumentiert ihn nicht. Seine interne Struktur deutet auf einen Reporting-Dienst hin, der über HTTP mit einem Apple-Backend kommuniziert und einen lokalen Cache pflegt. Er existiert auf gesunden Macs und ist an sich kein Problem.

Ist Es Malware?

Nein. Es ist ein Apple-Binary in /usr/libexec, gestartet von einem Launch Daemon innerhalb des versiegelten Systemvolumes. Sie können seine Signatur bestätigen:

codesign -dv --verbose=2 /usr/libexec/rtcreportingd

Wie Viel Speicherplatz Ist Für Roots Logs-Ordner Normal?

Auf einem gesunden Mac wenig – das ist kein Ordner, den Sie bemerken sollten. Wenn sudo du -sh /private/var/root/Library/Logs einen zweistelligen Gigabyte-Wert zurückgibt, ist das das Problem. Es gibt keinen offiziellen Apple-Schwellenwert; der praktische Test ist, ob er wächst, während der Mac im Leerlauf ist.

Behebt Eine Mac-Reinigungs-App Das Problem?

So gut wie sicher nicht, aus demselben Grund, aus dem Ihr Speicher-Analyse-Tool es übersehen hat: Wenn der Cleaner nicht seine Rechte erhöht und gezielt Roots Home-Verzeichnis durchsucht, kann er die Dateien nicht sehen. Und selbst ein Cleaner, der sie entfernt, würde nicht verhindern, dass sie zurückkommen, weil die Ursache ein sich wiederholender Prozess ist und kein angesammelter Datenmüll.

Betrifft Das Nur Bestimmte Macs Oder macOS-Versionen?

Es gibt nicht genug öffentliche Daten, um das zu sagen. Der dokumentierte Fall betraf ein M4 MacBook Air. Wir haben den Daemon und das Rechteverhalten unter macOS 26.5.2 verifiziert. Nichts am Mechanismus ist spezifisch für einen Chip oder eine macOS-Version – Root hat ein Home-Verzeichnis, seit es macOS gibt.

Sollte Ich Das Apple Melden?

Ja, wenn Sie es treffen. Fügen Sie die Ausgabe von sudo du -h -d 2 /private/var/root/, die CPU-Werte für rtcreportingd und fileproviderd bei sowie, welcher Sync-Client durch sein Beenden das Problem gelöst hat. Apple hat dazu nichts veröffentlicht, und konkrete Meldungen sind der Weg, wie sich das ändert.

Fazit

Dieses Problem ist deshalb so frustrierend, weil jeder Instinkt, den Sie zum Mac-Speicher haben, hier danebenliegt. Die Dateien liegen in keinem Ordner, den Sie finden können. Es sind keine Snapshots. Es ist keine System Data im Sinne der Speicher-Übersicht. Apps zu löschen hilft nicht, die Zahlen passen nicht zusammen, und das eine Tool, das es Ihnen zeigen würde, ist genau das, an dessen Ausführung mit sudo Sie nicht gedacht haben.

Sobald Sie wissen, wo Sie suchen müssen, ist es eine Zehn-Minuten-Aufgabe: /private/var/root mit du messen, die Logs löschen, Roots Papierkorb leeren, und dann – der Teil, der tatsächlich zählt – Activity Monitor beobachten, bis Sie den Prozess finden, der sie wieder auffüllt. Neun von zehn Mal ist es, wenn fileproviderd neben rtcreportingd in der CPU-Liste steht, ein Cloud-Sync-Client, der seit Monaten still vor sich hin defekt ist.

Und wenn die Speicherangaben Ihres Macs nur um ein paar Gigabyte statt um neunzig auseinandergehen, entspannen Sie sich. Das ist einfach APFS, das APFS ist, und Howard Oakleys Rechnung erklärt das vollständig.

Weiterführende Artikel: System Data storage huge on Mac and won't shrink · macOS storage management and optimization · Mac storage analyzer tools compared · iCloud Drive complete guide · macOS update stuck: not enough space

Quellen: Michael Tsai, „Huge RTCReporting Logs and Dropbox", 21. August 2026 · The Eclectic Light Company, „The arithmetic of free space", 21. August 2026 · Apple Support Community Thread 254838127 (RTCReporting) · Apple, Disk Utility Hilfe (purgeable space) · Eigene Verifikation unter macOS 26.5.2 (Build 25F84), 22. August 2026, mit ls, plutil, strings, df und ps.