Диск Mac заполнен, хотя видимых файлов нет? Проверьте папку логов root

Вот проблема с хранилищем, которая ставит в тупик практически любой инструмент, к которому обычно прибегают.

Mac сообщает, что диск почти заполнен. Вы открываете анализатор хранилища и складываете то, что он нашёл, — и итог оказывается на десятки гигабайт меньше, чем показывает macOS. Дисковая утилита не показывает никаких снапшотов. Вы удаляете приложения, выгружаете фото, очищаете корзину — а цифра почти не меняется. Перезагрузка помогает на час, а потом место снова исчезает.

Эти файлы реальны. Ваши инструменты просто не видят их, потому что они находятся в /private/var/root — домашней папке учётной записи root, — а каждый из этих инструментов запускается от вашего имени.

На тех Mac, где это бьёт больнее всего, основная масса — это одно: лог-файлы, которые пишет системный демон rtcreportingd, причём в объёмах, доходящих до десятков гигабайт. Michael Tsai задокументировал 21 августа 2026 года случай, когда одна только папка /private/var/root/Library/Logs занимала 74 ГБ на M4 MacBook Air, а после очистки за один день снова выросла до 27 ГБ.

Логи — это не болезнь. Это то, как выглядит зависший демон, когда никто не смотрит на термометр. В этой статье рассказано, как найти это место, как освободить его без классической ошибки, которая сводит на нет всю затею, и как найти процесс, который на самом деле его порождает.

Основные выводы

• /private/var/root невидим для всего, что запускается от имени вашего пользователя. Мы подтвердили на macOS 26.5.2, что ls /private/var/root возвращает Permission denied. Анализаторы хранилища, Finder и цифры использования в Дисковой утилите — все они упускают то, что находится внутри.
• rtcreportingd — это настоящий системный демон Apple, работающий от имени root. Мы проверили, что его задание launchd объявляет UserName => root, и именно поэтому его логи попадают в домашнюю папку root, а не в вашу.
• Заявленные размеры достигают десятков гигабайт и быстро восстанавливаются. 74 ГБ в задокументированном случае, снова 27 ГБ через день после удаления — потому что первопричина продолжала работать.
• Классическая ошибка сводит на нет всю работу. Удаление файлов через GUI-инструмент, запущенный под sudo, перемещает их в невидимую корзину root. Место не освобождается. Нужно удалять файлы сразу, минуя корзину, либо очищать корзину root.
• Ищите зависший клиент синхронизации. В задокументированном случае и rtcreportingd, и fileproviderd были прижаты почти к 100% загрузки процессора, и завершение работы Dropbox остановило оба процесса. fileproviderd — это процесс macOS, который обслуживает расширения File Provider облачных хранилищ.
• Не удаляйте в /private/var/root что попало. Логи и кэши удалять безопасно. Остальное — нет, и в этой статье чётко указано, что есть что.

Почему ваши инструменты анализа хранилища этого не видят

Прежде чем переходить к исправлению — механизм, потому что понимание именно его в следующий раз убережёт вас от погони не за той причиной.

У root есть домашняя папка, и демоны её используют

В macOS домашняя папка учётной записи root — это /private/var/root. Большинство людей считает, что она практически пуста и её касаются только тогда, когда запускают Terminal из macOS Recovery. Это не так уже много лет. Системные демоны, работающие от root и желающие хранить состояние, кэши или логи, пишут их именно туда, используя ту же структуру Library, что и ваша собственная домашняя папка:

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

Убедиться, что эта папка для вас закрыта, можно одной командой. На Mac, где Terminal не имеет повышенных привилегий:

ls /private/var/root

Мы выполнили именно эту команду на macOS 26.5.2 (сборка 25F84) и получили:

ls: /private/var/root: Permission denied

Это обычный Unix-отказ в доступе — домашняя папка root ограничена правами доступа только для root. Это не защита приватности TCC, и её не исправить через Полный доступ к диску (Full Disk Access). Анализатор хранилища, запущенный из Dock, работает от вашего имени, поэтому он обходит файловую систему как вы, и всё, что находится под этой папкой, — дыра на его карте.

Вот почему цифры не сходятся

Симптом, который описывают люди, — «мои итоги в инструменте анализа хранилища не сходятся», и вот причина. В задокументированном случае суммарные показатели папок в OmniDiskSweeper оказались примерно на 90 ГБ меньше, чем показывала macOS как используемое место.

Стоит отделить это от других причин, по которым цифры свободного места на Mac не сходятся, — таких причин несколько, и только одна из них — этот баг.

Howard Oakley 21 августа 2026 года разложил общую арифметику по полочкам, и цифры с его собственного Mac mini наглядно это иллюстрируют:

Источник	Показано как использовано на том же томе
Разница по контейнеру из diskutil apfs list	837.101 GB
Сумма Capacity Consumed по всем томам	837.027 GB
«Get Info» тома в Finder	826.67 GB
Дисковая утилита	814.03 GB

Четыре инструмента, четыре цифры, разброс около 23 ГБ — и ничего плохого не происходит. Разница возникает из-за учёта контейнера против тома, «удаляемого по требованию» (purgeable) пространства и особенностей поведения специальных файлов APFS:

• Контейнер против тома. Контейнер APFS вмещает несколько томов, которые совместно используют свободное место. «Свободное место на Macintosh HD» и «свободное место в контейнере» — это разные вопросы с разными ответами.
• Purgeable-пространство. macOS помечает часть контента как удаляемую по требованию — кэши, некоторые снапшоты, часть загруженного контента. Собственная справка Дисковой утилиты гласит: «вы не можете вручную удалить файлы, помеченные как purgeable, но macOS удаляет их по мере необходимости в месте». Oakley измерил 47.04 ГБ purgeable-пространства на своём томе Data.
• Специальные файлы. Клонированные файлы APFS используют общее хранилище, пока не разойдутся; разреженные (sparse) файлы хранят только ненулевые данные; часть системных файлов сжата; «безданные» (dataless) файлы держат данные в облаке и материализуются по требованию. Учёт свободного места опирается на то, что находится на диске сейчас.

Ничто из этого не порождает устойчивые, растущие, необъяснимые 90 ГБ. Если у вас небольшой и стабильный разрыв — это нормальный учёт. Если он большой и растёт, пока Mac простаивает без дела, — значит, что-то пишет файлы, которых вы не видите.

Более распространённую путаницу с хранилищем — не уменьшающиеся Системные данные, снапшоты, которые не освобождаются — мы разбираем отдельно в статьях System Data занимает огромный объём на Mac и руководстве по управлению хранилищем macOS. Сначала проверьте их. Эта статья — про случай, когда те объяснения не подходят.

Что такое rtcreportingd на самом деле

Будем честны насчёт границ наших знаний, потому что интернет вот-вот заполнится уверенными объяснениями демона, который Apple никогда не документировала.

Что мы проверили напрямую на macOS 26.5.2 (сборка 25F84):

Исполняемый файл находится по пути /usr/libexec/rtcreportingd и весит около 1.45 МБ. Его задание launchd лежит в /System/Library/LaunchDaemons/com.apple.rtcreportingd.plist и выглядит так:

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

Проверьте это на своём Mac — plist доступен для чтения всем:

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

UserName => root — это всё объяснение того, куда попадают логи. Демон, работающий от root и пишущий в ~/Library/Logs, пишет в /private/var/root/Library/Logs. Ничего экзотического тут нет.

Бинарник написан на Swift, и его внутренние имена классов видны через strings. Среди них BackendHTTP, TransparencyLog, StorebagCache, StorebagCoordinator, SessionCoordinator, XPCActivity и — обратите внимание на этот — CacheCleanupActivity. Среди имён его Mach-сервисов — com.apple.rtcreporting, com.apple.rtcreporting.pathmonitor и com.apple.rtcreportingd.storebag.

Чего мы вам не скажем — так это того, что означает «RTC» и о чём именно отчитывается демон. Apple это не документирует, а мы не собираемся выдумывать расшифровку аббревиатуры и выдавать её за факт. Имена классов подтверждают лишь скромное описание: это сервис отчётности или телеметрии, который общается с бэкендом Apple по HTTP, кэширует состояние локально, отслеживает доступность сетевого пути и имеет запланированную задачу для очистки собственного кэша.

Последняя деталь — самая интересная. У демона есть логика очистки. Когда его логи разрастаются до десятков гигабайт, разумное объяснение — не «Apple забыла настроить ротацию логов», а «что-то генерирует события быстрее, чем демон успевает их обрабатывать и подчищать за собой». А это указывает на то, что именно генерирует эти события.

Чтобы обозначить границу: это вывод из имён классов, а не утверждение о реализации Apple. Считайте это гипотезой, которая просто хорошо соответствует наблюдаемому поведению.

Как найти это место

Для всего этого вам понадобится sudo, и каждую команду стоит прочитать, прежде чем запускать.

1. Убедитесь, что разрыв действительно есть

Сначала — что, по мнению macOS, используется:

df -h / /System/Volumes/Data

На современном Mac вы получите две строки, потому что системный том — это запечатанный снапшот только для чтения, а ваши данные живут на отдельном томе в том же контейнере. На нашем тестовом Mac:

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

Обратите внимание, что обе строки показывают одинаковые Size и Avail — это общее свободное место контейнера, а не квота отдельного тома. Это то самое различие «контейнер против тома», о котором говорилось раньше, только в конкретных цифрах.

Затем проверьте снапшоты, чтобы исключить их:

diskutil apfs listSnapshots /System/Volumes/Data

И вид контейнера целиком:

diskutil apfs list

Если снапшотов минимум, а Capacity In Use контейнера намного выше того, что нашёл ваш анализатор хранилища, — у вас проблема с невидимыми файлами.

2. Измерьте домашнюю папку root

Вот команда, которая её находит:

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

-d 2 ограничивает глубину двумя уровнями — этого достаточно, чтобы увидеть, виноват ли Library/Logs или Library/Caches, не дожидаясь полного обхода. На машине с крупным «виновником» это может занять минуту-другую.

Для отсортированного списка главных «виновников» ещё на один уровень глубже:

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

На здоровом Mac эти итоги невелики — мегабайты, а не гигабайты. Если /private/var/root/Library/Logs выдаёт число с буквой «G» после него и больше одной цифры перед ней — это и есть ваше пропавшее место.

3. Посмотрите, что внутри

Прежде чем что-либо удалять, посмотрите:

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

В задокументированном случае содержимое было «почти полностью от RTCReporting». Если у вас доминирует что-то другое, это меняет ваши дальнейшие действия — диагностический подход из этой статьи всё равно применим, просто виновником окажется другая подсистема.

4. Альтернатива с графическим интерфейсом

Если вам удобнее видеть это в окне, OmniDiskSweeper бесплатен и именно он выявил проблему в первоисточнике. Важный момент: его нужно перезапустить с повышенными привилегиями, чтобы он увидел домашнюю папку root. При обычном запуске он покажет вам такую же неполную картину, как и всё остальное.

Наш обзор анализаторов хранилища рассматривает варианты, но учтите: то же ограничение применимо ко всем им — если инструмент не запущен от root, это место для него невидимо.

Как освободить это место — и ошибка, которая губит всю работу

Вот ловушка, и она весьма коварна.

Если вы удаляете эти файлы через GUI-инструмент, запущенный под sudo, он делает то, что делает всегда: перемещает их в корзину. Но поскольку процесс работает от root, это корзина root по пути /private/var/root/.Trash, которая не появляется в вашем Dock и которую вы никогда не додумаетесь очистить. Файлы остаются на диске. Свободное место не меняется. Вы делаете вывод, что удаление не сработало.

Конкретно в OmniDiskSweeper удерживайте Option, чтобы превратить Delete в Delete Immediately (удалить немедленно).

Из Terminal удалите содержимое логов напрямую:

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

Прочитайте эту команду, прежде чем её запускать. Она удаляет содержимое папки Logs root и ничего больше. Не сокращайте путь. Не добавляйте пробел перед слэшем.

Затем проверьте, не осталось ли чего-то в корзине root от предыдущей попытки:

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

И если да:

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

Кэши в домашней папке root тоже, как правило, безопасно очищать — по определению они восстанавливаемы:

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

Чего не трогать. Не удаляйте саму папку /private/var/root. Не удаляйте целиком /private/var/root/Library. Не удаляйте связки ключей, настройки или что-либо, что вы не узнаёте. Логи и кэши — безопасные категории; всё остальное там принадлежит какому-то системному компоненту, который поместил это туда не просто так.

После этого перезагрузитесь. Затем перепроверьте через df -h, чтобы убедиться, что место действительно вернулось.

Теперь найдите причину

Если остановиться на удалении, место вернётся, а потом снова исчезнет. В задокументированном случае оно вернулось к 5 ГБ за считаные минуты после перезагрузки и к 27 ГБ в течение дня.

Следите за загрузкой процессора

Откройте Activity Monitor, отсортируйте по % CPU и найдите два процесса:

• rtcreportingd — демон, пишущий логи
• fileproviderd — процесс macOS, который обслуживает расширения File Provider облачных хранилищ

В задокументированном случае оба процесса были постоянно прижаты почти к 100% загрузки процессора на бездействующем Mac.

Из Terminal:

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

Оба этих процесса существуют и работают на любом здоровом Mac — мы подтвердили, что оба работают на нашей тестовой машине, у которой вообще нет проблем с хранилищем. Их наличие — это нормально. А вот устойчивая загрузка процессора — нет. Несколько процентов во время синхронизации — это ожидаемо. А вот 90–100% на нетронутом Mac — это сигнал.

Следите за ростом логов

Самое прямое подтверждение — измерить дважды:

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

Подождите десять минут, не трогая Mac, и запустите снова. На здоровом Mac число заметно не меняется. Если оно ощутимо растёт, пока вы ничего не делаете, — значит, что-то зациклилось.

В первую очередь подозревайте облачную синхронизацию

fileproviderd — вот что вас выдаёт. Это системный процесс, обслуживающий расширения File Provider — современный механизм, который Dropbox, OneDrive, Google Drive, Box и iCloud Drive используют для отображения облачных файлов в Finder. Если он постоянно жжёт процессор, значит одно из этих расширений зависло.

В задокументированном случае клиентом был Dropbox — на Mac, где он вёл себя неправильно уже около года: не хранил файлы офлайн, как было настроено, и выглядел так, будто постоянно синхронизируется, хотя ничего не менялось. Завершение работы Dropbox немедленно остановило и загрузку процессора, и рост логов.

Чтобы проверить это на своём Mac, завершайте клиенты синхронизации по одному и наблюдайте. Завершайте клиент полностью — через значок в строке меню, Quit — а не просто ставьте синхронизацию на паузу, потому что расширение на паузе всё ещё может быть загружено.

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

Если завершение одного клиента опускает оба процесса до состояния простоя — вы нашли виновника.

Что делать с клиентом синхронизации

Варианты — примерно по возрастанию усилий:

1. Обновите его. Баги в расширениях File Provider — обычное дело, и их часто исправляют. Прежде всего проверьте наличие обновления.
2. Выйдите и снова войдите. Это пересобирает локальное состояние расширения и решает удивительно большое число случаев зависшей синхронизации.
3. Удалите и переустановите клиент. Более разрушительно, но более основательно.
4. Перенесите данные в другое место. В задокументированном случае итогом стала миграция в iCloud Drive — после того как Dropbox оказался не в состоянии надёжно скачать файлы для переноса, и автор в итоге скачал папку через веб-интерфейс Dropbox. После этого iCloud Drive «быстро всё загрузил, а затем перешёл в состояние без нагрузки на процессор».

Последний пункт стоит честно отметить: миграция между облачными провайдерами, когда исходный клиент сломан, — это по-настоящему мучительно, и веб-интерфейс может оказаться самым надёжным способом экспорта. Наше руководство по iCloud Drive описывает сторону назначения, а если сам iCloud Drive ведёт себя неправильно, баг автозагрузки iCloud Drive — это отдельная известная проблема.

Мы не утверждаем, что виноват именно Dropbox. Просто это клиент из задокументированного случая. Зависнуть может любое расширение File Provider, и диагностика одинакова, каким бы вы ни пользовались.

Другие места, где хранилище прячется от вас

Домашняя папка root — это то место, которое почти никто не проверяет, но не единственное, где инструмент уровня пользователя даёт осечку. Если ваш разрыв не в /private/var/root, пройдитесь по следующим пунктам, прежде чем решить, что цифры врут.

Данные других демонов, принадлежащие root. /private/var/root — это где живёт домашняя папка root, но системные компоненты также пишут в /private/var/db, /private/var/folders и /Library/Logs. Измеряйте их тем же способом:

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 хранит временные и кэш-контейнеры для каждого пользователя и вполне законно может достигать нескольких гигабайт. Ей управляет macOS, и в целом её лучше не трогать; перезагрузка очищает временные части.

Локальные снапшоты Time Machine. Это самая часто обвиняемая и реже всего действительно виновная причина. Проверяйте, а не предполагайте:

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

Если снапшоты действительно являются проблемой, macOS автоматически прореживает их под давлением нехватки места, а более глубокие случаи разобраны в нашем руководстве по устранению неполадок Time Machine.

Домашние папки других пользователей. Очевидно, стоит только сказать, но невидимо на практике — вторая учётная запись на Mac с 200 ГБ видео не то, что покажет вам инструмент хранилища, запущенный от вашего имени. sudo du -h -d 1 /Users отвечает на это одной строкой.

Файлы, удерживаемые открытыми работающим процессом. Место, которое было удалено, но не освобождено, потому что процесс всё ещё держит дескриптор файла. Это проявляется как разрыв, который исчезает после перезагрузки:

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

Локальное хранилище Mail, резервные копии устройств iOS и Xcode. Три классические большие и забытые папки на Mac разработчика или активного пользователя Mail:

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

Все они читаемы от вашего собственного пользователя, так что анализатор хранилища их найдёт — они просто теряются в длинном списке. Стоит проверить их, прежде чем переходить к sudo.

Материализовавшиеся облачные файлы-заглушки. Если вы используете настройку «хранить файлы только онлайн» в каком-либо клиенте синхронизации, баг или полнотекстовый поиск может тихо скачать всё целиком. Это тот же класс сбоя, что и в этой статье, и обычно проявляется как устойчивый рост самой папки синхронизации.

Насколько это распространено?

Честный ответ: мы не знаем, и никто из тех, кто пишет об этом, тоже не знает.

В публичном доступе есть свидетельство из первых рук с конкретными цифрами и конкретным решением, тема на Apple Support Community про хранилище RTCReporting и тред на Reddit, где пользователи спрашивают, что занимает их место. Этого достаточно, чтобы установить, что проблема реальна и воспроизводима, но недостаточно, чтобы сказать, какая доля Mac ей подвержена.

Что мы можем сказать по итогам собственной проверки: rtcreportingd работает на стоковом Mac без проблем с хранилищем, его логи там ничем не примечательны, а у демона есть логика очистки, которая, судя по всему, в большинстве случаев работает. Это режим сбоя, а не поведение по умолчанию. Если у вашего Mac цифры хранилища сходятся, чинить нечего.

Apple не опубликовала ни одного документа поддержки об этом, не признала проблему и не выпустила задокументированного исправления. Если вы столкнулись с этим, потратить пять минут на отправку отзыва Apple того стоит — непризнанная проблема так и остаётся непризнанной.

Решение распространённых проблем

sudo du выполняется бесконечно долго

Это нормально на большом или сильно фрагментированном дереве папок. Сначала используйте -d 1, чтобы найти, какая папка верхнего уровня большая, а затем спускайтесь только в неё. Избегайте запуска du по всему диску, когда вы уже знаете, какая папка вас интересует.

Я удалил логи, но свободное место не изменилось

Проблема с корзиной. Проверьте sudo du -sh /private/var/root/.Trash и очистите её через sudo rm -rf /private/var/root/.Trash/*. В эту ловушку попадает почти каждый, кто пользовался GUI-инструментом.

Вторая возможность — какой-то процесс всё ещё держит удалённые файлы открытыми, и в этом случае место не освобождается, пока процесс не завершится. Перезагрузите Mac и проверьте снова.

Место снова заполнилось в течение дня

Ожидаемо, если вы не нашли причину. Удаление логов лечит симптом. Перейдите к шагу с Activity Monitor и найдите, что зациклилось.

rtcreportingd нагружает процессор, а облачных клиентов синхронизации у меня нет

Значит, триггер — что-то другое. Отсортируйте Activity Monitor по CPU и посмотрите, что ещё занято. Проверьте единый лог (unified log) на предмет активности самого демона:

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

Учтите, что запросы к единому логу возвращают только то, что действительно было записано, а данные логов со временем устаревают и удаляются — запрос за долгий период вполне законно может не вернуть ничего.

Первая помощь Дисковой утилиты говорит, что с диском всё в порядке

Так и будет. Это не повреждение файловой системы. Первая помощь проверяет согласованность метаданных; папка, полная больших, но валидных файлов, полностью согласованна.

Можно ли просто отключить rtcreportingd?

Мы бы не стали. Это системный демон Apple на Mac с System Integrity Protection, а отключение системных демонов запуска ради обхода симптома обычно позже порождает вторую, менее очевидную проблему. Вместо этого устраните процесс, который его подстёгивает. Если демон ведёт себя неправильно без выявляемого триггера — это баг Apple, о котором стоит сообщить, а не обходить его.

У моего Mac заканчивается место, и оно нужно прямо сейчас

Немедленные безопасные шаги, пока вы диагностируете: очистите свою собственную корзину, очистите корзину root, как описано выше, удалите содержимое Logs root и проверьте sudo du -h -d 1 /private/var/root/Library/Caches. Вместе они часто освобождают достаточно места, чтобы снова сделать Mac пригодным для использования, пока вы ищете причину. Наше руководство по сбоям обновления из-за нехватки места описывает, что делать, если это конкретно блокирует обновление macOS.

Часто задаваемые вопросы

Что такое /private/var/root?

Это домашняя папка учётной записи root в macOS. Читать её может только root, поэтому инструменты, работающие от имени вашего пользователя, не видят, что внутри. Системные демоны, работающие от root, хранят там логи, кэши и состояние, используя ту же структуру Library, что и ваша собственная домашняя папка.

Почему Finder или моё приложение для хранилища не видят эти файлы?

Потому что они работают от вашего имени, а Unix-права папки исключают вашего пользователя. Это не защита приватности, которую можно снять через Полный доступ к диску, — это обычные права доступа к файлам. Чтобы обойти эту папку, GUI-инструмент нужно перезапустить с повышенными привилегиями.

Что такое rtcreportingd?

Системный демон Apple по пути /usr/libexec/rtcreportingd, запускаемый через com.apple.rtcreportingd и работающий от root. Apple его не документирует. Его внутренняя структура указывает на сервис отчётности, который общается с бэкендом Apple по HTTP и поддерживает локальный кэш. Он существует на здоровых Mac и сам по себе проблемой не является.

Это вредоносное ПО?

Нет. Это бинарник Apple в /usr/libexec, запускаемый launch-демоном внутри запечатанного системного тома. Вы можете проверить его подпись:

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

Сколько места нормально для папки Logs root?

На здоровом Mac — немного, эту папку вы вообще не должны замечать. Если sudo du -sh /private/var/root/Library/Logs возвращает что-то в двузначных гигабайтах — это и есть проблема. Официального порога от Apple нет; практический тест — растёт ли она, пока Mac простаивает.

Поможет ли приложение для чистки Mac?

Почти наверняка нет, по той же причине, по которой ваш анализатор хранилища это пропустил: если чистильщик не повышает привилегии и не обходит специально домашнюю папку root, он не увидит эти файлы. И даже чистильщик, который бы их удалил, не помешал бы им вернуться, потому что причина — зациклившийся процесс, а не накопленный мусор.

Затрагивает ли это только определённые Mac или версии macOS?

Публичных данных недостаточно, чтобы сказать наверняка. Задокументированный случай произошёл на M4 MacBook Air. Мы проверили демона и поведение прав доступа на macOS 26.5.2. В самом механизме нет ничего специфичного для конкретного чипа или версии macOS — у root есть домашняя папка с тех пор, как существует macOS.

Стоит ли сообщать об этом Apple?

Да, если вы с этим столкнулись. Приложите вывод sudo du -h -d 2 /private/var/root/, цифры загрузки процессора для rtcreportingd и fileproviderd, а также то, остановка какого клиента синхронизации решила проблему. Apple не опубликовала об этом ничего, и именно конкретные отчёты меняют такое положение дел.

Заключение

Эта проблема так раздражает потому, что все ваши инстинкты насчёт хранилища на Mac в этом случае ошибочны. Файлы не в папке, которую можно найти. Это не снапшоты. Это не Системные данные в том смысле, который вкладывает панель «Хранилище». Удаление приложений не помогает, цифры не сходятся, а единственный инструмент, который бы всё показал, — тот, который вы не додумались запустить через sudo.

Как только вы знаете, куда смотреть, это работа на десять минут: измерьте /private/var/root через du, удалите логи, очистите корзину root, а затем — та часть, что на самом деле важна, — следите за Activity Monitor, пока не найдёте процесс, который наполняет их заново. В девяти случаях из десяти, если fileproviderd соседствует с rtcreportingd в списке по CPU, это клиент облачной синхронизации, который месяцами тихо был сломан.

А если цифры хранилища на вашем Mac расходятся на несколько гигабайт, а не на девяносто, — расслабьтесь. Это просто APFS ведёт себя как APFS, и арифметика Howard Oakley всё это объясняет.

Похожие материалы: System Data занимает огромный объём на Mac и не уменьшается · Управление хранилищем и оптимизация в macOS · Сравнение инструментов анализа хранилища Mac · Полное руководство по iCloud Drive · Обновление macOS зависает: не хватает места

Источники: Michael Tsai, «Huge RTCReporting Logs and Dropbox», 21 августа 2026 · The Eclectic Light Company, «The arithmetic of free space», 21 августа 2026 · тема Apple Support Community 254838127 (RTCReporting) · Apple, Disk Utility Help (purgeable space) · Локальная проверка на macOS 26.5.2 (сборка 25F84), 22 августа 2026, с использованием ls, plutil, strings, df и ps.