Disco do Mac cheio sem motivo aparente? Veja a pasta de logs do root

Aqui está um problema de armazenamento que derrota praticamente todas as ferramentas que a maioria das pessoas costuma usar.

Seu Mac diz que o disco está quase cheio. Você abre um analisador de armazenamento e soma o que ele encontrou — e o total fica dezenas de gigabytes abaixo do que o macOS afirma estar em uso. O Disk Utility não reporta snapshots. Você apaga aplicativos, transfere fotos, esvazia a Lixeira, e o número quase não se mexe. Reiniciar ajuda por uma hora, depois o espaço some de novo.

Os arquivos são reais. Suas ferramentas não conseguem vê-los porque eles vivem em /private/var/root — a pasta pessoal (home) da conta root — e cada uma dessas ferramentas está rodando como você.

Nos Macs onde isso morde mais forte, a maior parte é uma coisa só: arquivos de log escritos por um daemon do sistema chamado rtcreportingd, em quantidades que chegam a dezenas de gigabytes. Michael Tsai documentou um caso em 21 de agosto de 2026 em que /private/var/root/Library/Logs sozinho consumia 74 GB em um MacBook Air M4, e em que a pasta voltou a 27 GB em um único dia depois de ter sido esvaziada.

Os logs não são a doença. Eles são a cara de um daemon travado quando ninguém está olhando o termômetro. Este artigo cobre como encontrar o espaço, como recuperá-lo sem o erro clássico que desperdiça todo o esforço, e como encontrar o processo que está de fato gerando isso.

Principais conclusões

• /private/var/root é invisível para qualquer coisa rodando como o seu usuário. Confirmamos no macOS 26.5.2 que ls /private/var/root retorna Permission denied. Analisadores de armazenamento, o Finder e os números de uso do Disk Utility deixam tudo o que está dentro dela de fora.
• rtcreportingd é um daemon real do sistema da Apple que roda como root. Verificamos que seu job do launchd declara UserName => root, e é exatamente por isso que seus logs vão parar na pasta pessoal do root, e não na sua.
• Os tamanhos relatados chegam a dezenas de gigabytes, e voltam a crescer rápido. 74 GB em um caso documentado, de volta a 27 GB em um dia após a exclusão, porque a causa raiz ainda estava rodando.
• O erro clássico desperdiça todo o trabalho. Apagar arquivos com uma ferramenta gráfica rodando sob sudo move os arquivos para a Lixeira do root. O espaço não é recuperado. É preciso apagar imediatamente, ou esvaziar a Lixeira do root.
• Procure por um cliente de sincronização travado. No caso documentado, rtcreportingd e fileproviderd estavam cada um preso perto de 100% de CPU, e encerrar o Dropbox parou os dois. O fileproviderd é o processo do macOS que hospeda as extensões File Provider de armazenamento em nuvem.
• Não saia apagando coisas em /private/var/root de forma aleatória. Logs e caches são seguros de remover. Outras coisas ali não são, e este artigo é específico sobre qual é qual.

Por que suas ferramentas de armazenamento não conseguem ver isso

Antes da solução, o mecanismo — porque entendê-lo é o que evita que você persiga a coisa errada da próxima vez.

O root tem uma pasta pessoal, e os daemons a usam

No macOS, a pasta pessoal da conta root é /private/var/root. A maioria das pessoas assume que ela é essencialmente vazia e só é tocada quando você roda o Terminal a partir do macOS Recovery. Isso não é verdade há anos. Daemons do sistema que rodam como root e querem armazenar estado, caches ou logs os escrevem ali, na mesma estrutura de Library que a sua própria pasta pessoal usa:

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

Você pode confirmar que a pasta está fora do seu alcance com um único comando. Em um Mac onde o Terminal não tem privilégios elevados:

ls /private/var/root

Rodamos exatamente isso no macOS 26.5.2 (build 25F84) e obtivemos:

ls: /private/var/root: Permission denied

Essa é uma negação de permissão Unix comum — a pasta pessoal do root tem restrição de modo para o próprio root. Não é uma proteção de privacidade do TCC e não é algo que o Acesso Total ao Disco resolva. Um analisador de armazenamento que você abriu pelo Dock roda como você, então ele percorre o sistema de arquivos como você, e tudo dentro daquela pasta é um buraco no mapa dele.

É por isso que os números não batem

O sintoma que as pessoas descrevem é "os totais da minha ferramenta de armazenamento não fecham", e essa é a razão. No caso documentado, os totais de pastas do OmniDiskSweeper ficaram cerca de 90 GB abaixo do que o macOS relatava como usado.

Vale separar isso das outras razões pelas quais os números de espaço livre do Mac não batem, porque existem várias e apenas uma delas é esse bug.

Howard Oakley detalhou a aritmética geral em 21 de agosto de 2026, e os números do próprio Mac mini dele deixam o ponto claro:

Fonte	Reportado como usado no mesmo volume
Diferença do container em diskutil apfs list	837,101 GB
Soma da Capacidade Consumida por volume	837,027 GB
Obter Informações do Finder sobre o volume	826,67 GB
Disk Utility	814,03 GB

Quatro ferramentas, quatro números, uma variação de cerca de 23 GB, e nada de errado. As diferenças vêm da contabilidade container-versus-volume, do espaço purgável e do comportamento de arquivos especiais do APFS:

• Container versus volume. Um container APFS abriga vários volumes que compartilham espaço livre. "Espaço livre no Macintosh HD" e "espaço livre no container" são perguntas diferentes com respostas diferentes.
• Espaço purgável. O macOS marca parte do conteúdo como removível sob demanda — caches, alguns snapshots, alguns conteúdos baixados. O próprio manual de ajuda do Disk Utility diz que "você não pode remover manualmente os arquivos designados como purgáveis, mas o macOS os remove conforme o espaço é necessário." Oakley mediu 47,04 GB purgáveis no volume de Dados dele.
• Arquivos especiais. Arquivos clone do APFS compartilham armazenamento até divergirem; arquivos esparsos armazenam apenas seus dados não nulos; alguns arquivos do sistema são compactados; arquivos "dataless" mantêm seus dados na nuvem e os materializam sob demanda. A contabilidade de espaço livre usa o que está no disco agora.

Nada disso produz um gap persistente, crescente e inexplicado de 90 GB. Se a sua diferença é pequena e estável, é contabilidade normal. Se é grande e cresce enquanto o Mac fica parado, algo está escrevendo arquivos que você não consegue ver.

Para as confusões de armazenamento mais comuns — Dados do Sistema que não encolhem, snapshots que não liberam — cobrimos isso separadamente em Dados do Sistema ocupando espaço enorme no Mac e no guia de gerenciamento de armazenamento do macOS. Confira esses primeiro. Este artigo trata do caso em que essas explicações não se encaixam.

O que o rtcreportingd realmente é

Vamos ser honestos sobre os limites aqui, porque a internet está prestes a se encher de explicações confiantes sobre um daemon que a Apple nunca documentou.

O que verificamos diretamente, no macOS 26.5.2 (build 25F84):

O executável existe em /usr/libexec/rtcreportingd e tem cerca de 1,45 MB. Seu job do launchd está em /System/Library/LaunchDaemons/com.apple.rtcreportingd.plist, e diz:

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

Confira no seu próprio Mac — o plist pode ser lido por qualquer usuário:

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

UserName => root é toda a explicação de para onde vão os logs. Um daemon rodando como root que escreve em ~/Library/Logs escreve em /private/var/root/Library/Logs. Não há nada de exótico nisso.

O binário é escrito em Swift, e os nomes internos de suas classes são visíveis com strings. Eles incluem BackendHTTP, TransparencyLog, StorebagCache, StorebagCoordinator, SessionCoordinator, XPCActivity e — atenção a este — CacheCleanupActivity. Os nomes de seus serviços Mach incluem com.apple.rtcreporting, com.apple.rtcreporting.pathmonitor e com.apple.rtcreportingd.storebag.

O que não vamos dizer é o que "RTC" significa ou precisamente o que o daemon reporta. A Apple não documenta isso, e não vamos inventar uma expansão da sigla e apresentá-la como fato. O que os nomes das classes sustentam é uma descrição modesta: é um serviço de relatório ou telemetria que conversa com um backend da Apple via HTTP, mantém estado em cache localmente, monitora a disponibilidade de rotas de rede, e tem uma atividade agendada para limpar seu próprio cache.

Esse último detalhe é o interessante. O daemon tem lógica de limpeza. Quando seus logs crescem a dezenas de gigabytes, a leitura razoável não é "a Apple esqueceu de rotacionar os logs", mas "algo está gerando eventos mais rápido do que o daemon consegue processar e limpar depois deles". O que aponta para o que quer que esteja gerando esses eventos.

Para deixar o limite claro: isso é uma inferência a partir dos nomes das classes, não uma afirmação sobre a implementação da Apple. Trate como uma hipótese que por acaso se encaixa no comportamento observado.

Encontrando o espaço

Você vai precisar de sudo para tudo isso, e deve ler cada comando antes de executá-lo.

1. Confirme que o gap existe

Primeiro, o que o macOS acha que está em uso:

df -h / /System/Volumes/Data

Em um Mac moderno você recebe duas linhas, porque o volume do sistema é um snapshot somente leitura selado e seus dados vivem em um volume separado no mesmo container. No nosso Mac de teste:

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

Note que ambos relatam o mesmo Size e Avail — esse é o espaço livre compartilhado do container, não uma cota por volume. Essa é a distinção container-versus-volume de antes, tornada concreta.

Em seguida, confira os snapshots, para poder descartá-los:

diskutil apfs listSnapshots /System/Volumes/Data

E a visão do container:

diskutil apfs list

Se os snapshots forem mínimos e a Capacidade em Uso do container estiver bem acima do que seu analisador de armazenamento encontrou, você tem um problema de arquivos invisíveis.

2. Meça a pasta pessoal do root

Este é o comando que encontra o problema:

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

-d 2 limita a profundidade a dois níveis, o que é suficiente para ver se Library/Logs ou Library/Caches é o culpado, sem esperar por uma varredura completa. Espere que leve um ou dois minutos em uma máquina com um infrator grande.

Para uma visão ordenada dos piores infratores um nível mais fundo:

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

Em um Mac saudável esses totais são pequenos — megabytes, não gigabytes. Se /private/var/root/Library/Logs retornar um número com "G" depois e mais de um dígito na frente, esse é o seu espaço desaparecido.

3. Veja o que há dentro

Antes de apagar qualquer coisa, olhe:

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

No caso documentado, o conteúdo era "quase inteiramente do RTCReporting". Se o seu for dominado por outra coisa, isso muda o que você deve fazer — a abordagem de diagnóstico deste artigo ainda se aplica, mas o culpado será um subsistema diferente.

4. Uma alternativa gráfica

Se preferir ver isso em uma janela, o OmniDiskSweeper é gratuito e foi o que revelou o problema no relato original. A parte importante é que você precisa reabri-lo com privilégios elevados para que ele consiga ver a pasta pessoal do root. Aberto normalmente, ele mostrará o mesmo panorama incompleto que todo o resto.

Nosso resumo de analisadores de armazenamento cobre as opções, mas esteja ciente de que a mesma limitação se aplica a todas elas: se a ferramenta não está rodando como root, esse espaço é invisível para ela.

Recuperando o espaço — e o erro que desperdiça todo o trabalho

Aqui está a armadilha, e é uma boa.

Se você apagar esses arquivos com uma ferramenta gráfica rodando sob sudo, a ferramenta faz o que sempre faz: move os arquivos para a Lixeira. Mas como o processo está rodando como root, essa é a Lixeira do root, em /private/var/root/.Trash, que não aparece no seu Dock e que você jamais pensaria em esvaziar. Os arquivos continuam no disco. Seu espaço livre não muda. Você conclui que a exclusão não funcionou.

No OmniDiskSweeper especificamente, segure Option para transformar Delete em Delete Immediately.

Pelo Terminal, apague o conteúdo dos logs diretamente:

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

Leia esse comando antes de executá-lo. Ele remove o conteúdo da pasta Logs do root e nada mais. Não abrevie o caminho. Não adicione um espaço antes da barra.

Depois, verifique se há algo parado na Lixeira do root de uma tentativa anterior:

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

E, se houver:

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

Caches na pasta pessoal do root também são, em geral, seguros de limpar — eles são, por definição, regeneráveis:

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

O que não tocar. Não apague /private/var/root em si. Não apague /private/var/root/Library por inteiro. Não saia removendo chaveiros, preferências ou qualquer coisa que você não reconheça. Logs e caches são as categorias seguras; tudo o mais ali pertence a um componente do sistema que o colocou lá por um motivo.

Reinicie depois. Em seguida, verifique novamente com df -h para confirmar que o espaço realmente voltou.

Agora encontre o que está causando isso

Se você parar na exclusão, o espaço volta e depois some de novo. No caso documentado, ele já estava de volta a 5 GB minutos depois de um reinício e a 27 GB dentro de um dia.

Observe a CPU

Abra o Monitor de Atividade, ordene por % CPU, e procure por dois processos:

• rtcreportingd — o daemon que escreve os logs
• fileproviderd — o processo do macOS que hospeda extensões File Provider de armazenamento em nuvem

No caso documentado, ambos estavam presos perto de 100% de CPU continuamente, em um Mac ocioso.

Pelo Terminal:

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

Ambos os processos existem e rodam em qualquer Mac saudável — confirmamos os dois rodando na nossa máquina de teste, que não tem nenhum problema de armazenamento. A presença deles é normal. O uso sustentado de CPU não é. Alguns por cento enquanto uma sincronização está em andamento é esperado. Ficar em 90–100% com o Mac intocado é o sinal.

Observe os logs crescerem

A confirmação mais direta é medir duas vezes:

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

Espere dez minutos com o Mac ocioso, e execute de novo. Em um Mac saudável, o número não se move de forma significativa. Se ele subir de forma perceptível enquanto você não faz nada, algo está em loop.

Suspeite primeiro da sincronização em nuvem

O fileproviderd é a pista. Ele é o processo do sistema que hospeda extensões File Provider — o mecanismo moderno que Dropbox, OneDrive, Google Drive, Box e iCloud Drive usam para apresentar arquivos na nuvem no Finder. Se ele está consumindo CPU continuamente, uma dessas extensões está travada.

No caso documentado, o cliente era o Dropbox, em um Mac onde ele vinha se comportando mal havia cerca de um ano — não mantendo arquivos offline como configurado, e parecendo sincronizar constantemente quando nada havia mudado. Encerrar o Dropbox parou imediatamente tanto o uso de CPU quanto o crescimento dos logs.

Para testar isso no seu próprio Mac, encerre seus clientes de sincronização um de cada vez e observe. Encerre o cliente completamente — ícone na barra de menus, Quit — em vez de apenas pausar a sincronização, porque uma extensão pausada ainda pode continuar carregada.

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

Se encerrar um cliente derrubar ambos os processos para o estado ocioso, você encontrou o culpado.

O que fazer em relação ao cliente de sincronização

Opções, aproximadamente em ordem de esforço:

1. Atualize-o. Bugs de extensões File Provider são comuns e frequentemente corrigidos. Verifique se há uma atualização antes de qualquer outra coisa.
2. Saia e entre de novo. Isso reconstrói o estado local da extensão e resolve uma quantidade surpreendente de casos de sincronização travada.
3. Remova e reinstale o cliente. Mais disruptivo, mas mais completo.
4. Mova os dados para outro lugar. No caso documentado, o desfecho foi a migração para o iCloud Drive, depois que o Dropbox se mostrou incapaz de baixar os arquivos de forma confiável para a mudança — o autor acabou baixando a pasta pela interface web do Dropbox. O iCloud Drive então "enviou tudo rapidamente e depois se estabilizou em um estado sem uso de CPU."

Esse último ponto vale sinalizar com honestidade: migrar entre provedores de nuvem quando o cliente de origem está quebrado é genuinamente doloroso, e a interface web pode ser o seu caminho de exportação mais confiável. Nosso guia do iCloud Drive cobre o lado do destino, e se o próprio iCloud Drive estiver se comportando mal, o bug de download automático do iCloud Drive é um problema separado já conhecido.

Não estamos dizendo que o Dropbox seja o único culpado. Ele é o cliente do caso documentado. Qualquer extensão File Provider pode travar, e o diagnóstico é o mesmo, seja qual for a que você usa.

Os outros lugares onde o armazenamento se esconde de você

A pasta pessoal do root é a que quase ninguém confere, mas não é o único lugar onde uma ferramenta em nível de usuário fica devendo. Se o seu gap não está em /private/var/root, passe por estes antes de concluir que os números estão mentindo.

Dados de outros daemons pertencentes ao root. /private/var/root é onde fica a pasta pessoal do root, mas componentes do sistema também escrevem em /private/var/db, /private/var/folders e /Library/Logs. Meça-os da mesma forma:

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 guarda contêineres temporários e de cache por usuário e pode legitimamente chegar a vários gigabytes. É gerenciado pelo macOS e, em geral, deve ser deixado em paz; um reinício limpa as partes voláteis.

Snapshots locais do Time Machine. Estes são a causa mais culpada e menos frequentemente responsável. Confira em vez de presumir:

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

Se os snapshots realmente forem o problema, o macOS os afina automaticamente sob pressão de espaço, e os casos mais profundos estão cobertos no nosso guia de solução de problemas do Time Machine.

Pastas pessoais de outros usuários. Óbvio quando dito, invisível na prática — uma segunda conta no Mac com 200 GB de vídeo não é algo que sua ferramenta de armazenamento mostrará enquanto roda como você. sudo du -h -d 1 /Users responde isso em uma linha.

Arquivos mantidos abertos por um processo em execução. Espaço que foi apagado mas não liberado, porque um processo ainda tem o descritor de arquivo aberto. Isso aparece como um gap que some depois de um reinício:

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

Armazenamento local do Mail, backups de dispositivos iOS e Xcode. Os três diretórios clássicos, grandes e esquecidos, no Mac de um desenvolvedor ou de um usuário pesado do Mail:

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

Todos esses são legíveis como seu próprio usuário, então um analisador de armazenamento vai encontrá-los — eles só se perdem em uma lista longa. Vale a pena checar antes de escalar para o sudo.

Arquivos placeholder de nuvem que se materializaram. Se você usa uma configuração de "manter arquivos só online" em algum cliente de sincronização, um bug ou uma busca de texto completo pode silenciosamente baixar tudo. Essa é a mesma classe de falha deste artigo e costuma aparecer como crescimento constante na própria pasta de sincronização.

Quão comum é isso?

Resposta honesta: não sabemos, e ninguém mais que publica sobre isso sabe também.

O que existe no registro público é um relato em primeira mão com números e uma correção específicos, uma thread da Comunidade de Suporte da Apple sobre armazenamento do RTCReporting, e uma thread no Reddit de usuários perguntando o que estava ocupando o armazenamento deles. Isso é suficiente para estabelecer que o problema é real e reproduzível, e não é suficiente para dizer qual proporção de Macs é afetada.

O que podemos dizer com base na nossa própria checagem: o rtcreportingd roda em um Mac padrão sem problema de armazenamento, seus logs ali são banais, e o daemon tem lógica de limpeza que evidentemente funciona na maior parte do tempo. Este é um modo de falha, não um comportamento padrão. Se as contas de armazenamento do seu Mac fecham, você não tem nada a corrigir.

A Apple não publicou nenhum documento de suporte sobre isso, não reconheceu o problema, e não lançou uma correção documentada. Se você se deparar com isso, registrar um feedback com a Apple vale os cinco minutos — um problema não reconhecido permanece não reconhecido.

Solução de problemas comuns

O sudo du está demorando uma eternidade

Isso é normal em uma árvore de diretórios grande ou muito fragmentada. Use -d 1 primeiro para encontrar qual pasta de nível superior é grande, depois desça apenas nela. Evite rodar du no disco inteiro quando você já sabe qual diretório interessa.

Apaguei os logs mas o espaço livre não mudou

O problema da Lixeira. Verifique sudo du -sh /private/var/root/.Trash e esvazie com sudo rm -rf /private/var/root/.Trash/*. Isso pega quase todo mundo que usou uma ferramenta gráfica.

A segunda possibilidade é que um processo ainda tem os arquivos apagados abertos, caso em que o espaço não é liberado até o processo terminar. Reinicie o Mac e verifique de novo.

O espaço voltou dentro de um dia

Esperado, se você ainda não encontrou a causa. Apagar os logs trata o sintoma. Vá até a etapa do Monitor de Atividade e encontre o que está em loop.

O rtcreportingd está usando CPU mas eu não tenho clientes de sincronização em nuvem

Então o gatilho é outra coisa. Ordene o Monitor de Atividade por CPU e veja o que mais está ocupado. Confira o log unificado quanto à atividade do próprio daemon:

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

Esteja ciente de que as consultas ao log unificado só retornam o que foi de fato escrito, e os dados de log expiram — uma consulta em uma janela longa pode legitimamente não retornar nada.

O First Aid do Disk Utility diz que o disco está bem

Vai dizer mesmo. Isso não é corrupção de sistema de arquivos. O First Aid verifica a consistência dos metadados; um diretório cheio de arquivos grandes e válidos é perfeitamente consistente.

Posso simplesmente desativar o rtcreportingd?

Não recomendaríamos. É um daemon do sistema da Apple em um Mac com System Integrity Protection, e desativar daemons de sistema para contornar um sintoma tende a produzir um segundo problema, menos óbvio, mais tarde. Corrija o processo que está impulsionando isso em vez disso. Se o daemon está se comportando mal sem gatilho identificável, isso é um bug da Apple que vale a pena reportar, não contornar.

Meu Mac está ficando sem espaço e preciso de espaço agora

Vitórias imediatas e seguras enquanto você diagnostica: esvazie sua própria Lixeira, esvazie a Lixeira do root como acima, apague o conteúdo dos Logs do root, e verifique sudo du -h -d 1 /private/var/root/Library/Caches. Juntas, essas ações costumam liberar espaço suficiente para deixar o Mac utilizável de novo enquanto você encontra a causa. Nosso guia sobre falhas de atualização causadas por espaço insuficiente cobre o que fazer se isso estiver bloqueando especificamente uma atualização do macOS.

Perguntas frequentes

O que é /private/var/root?

É a pasta pessoal (home) da conta root no macOS. Ela é legível apenas pelo root, e é por isso que ferramentas rodando como o seu usuário não conseguem ver o que há dentro dela. Daemons do sistema que rodam como root armazenam ali logs, caches e estado, usando a mesma estrutura de Library que a sua própria pasta pessoal.

Por que o Finder ou meu aplicativo de armazenamento não conseguem ver esses arquivos?

Porque eles rodam como você, e as permissões Unix da pasta excluem o seu usuário. Isso não é uma proteção de privacidade que o Acesso Total ao Disco possa liberar — são permissões de arquivo comuns. Uma ferramenta gráfica precisa ser reaberta com privilégios elevados para percorrer aquela pasta.

O que é o rtcreportingd?

Um daemon do sistema da Apple em /usr/libexec/rtcreportingd, iniciado por com.apple.rtcreportingd e rodando como root. A Apple não o documenta. Sua estrutura interna indica um serviço de relatório que se comunica com um backend da Apple via HTTP e mantém um cache local. Ele existe em Macs saudáveis e não é, por si só, um problema.

É malware?

Não. É um binário da Apple em /usr/libexec, iniciado por um daemon de inicialização dentro do volume de sistema selado. Você pode confirmar sua assinatura:

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

Quanto espaço é normal para a pasta Logs do root?

Em um Mac saudável, pouco — essa não deveria ser uma pasta que você chega a notar. Se sudo du -sh /private/var/root/Library/Logs retornar algo em gigabytes de dois dígitos, esse é o problema. Não há um limiar oficial da Apple; o teste prático é se ela cresce enquanto o Mac está ocioso.

Um aplicativo de limpeza para Mac resolve isso?

Quase certamente não, pela mesma razão pela qual seu analisador de armazenamento perdeu isso: a menos que o limpador eleve privilégios e percorra especificamente a pasta pessoal do root, ele não consegue ver os arquivos. E mesmo um limpador que os removesse não impediria que voltassem, porque a causa é um processo em loop, não acúmulo de lixo.

Isso afeta apenas certos Macs ou versões do macOS?

Não há dados públicos suficientes para dizer. O caso documentado foi um MacBook Air M4. Verificamos o daemon e o comportamento de permissões no macOS 26.5.2. Nada no mecanismo é específico de um chip ou de uma versão do macOS — o root tem uma pasta pessoal desde que o macOS existe.

Devo reportar isso à Apple?

Sim, se você se deparar com isso. Inclua a saída de sudo du -h -d 2 /private/var/root/, os números de CPU de rtcreportingd e fileproviderd, e qual cliente de sincronização, ao ser encerrado, resolveu o problema. A Apple não publicou nada sobre isso, e relatos específicos são como isso muda.

Conclusão

O motivo pelo qual esse problema é tão frustrante é que todo instinto que você tem sobre armazenamento do Mac está errado para ele. Os arquivos não estão em uma pasta que você consiga encontrar. Não são snapshots. Não são Dados do Sistema no sentido em que o painel de Armazenamento usa o termo. Apagar aplicativos não ajuda, os números não fecham, e a única ferramenta que mostraria isso é a que você não pensou em rodar com sudo.

Uma vez que você sabe onde olhar, é um trabalho de dez minutos: meça /private/var/root com du, apague os logs, esvazie a Lixeira do root, e então — a parte que realmente importa — observe o Monitor de Atividade até encontrar o processo que está enchendo tudo de novo. Nove em cada dez vezes, com o fileproviderd ao lado do rtcreportingd na lista de CPU, esse processo é um cliente de sincronização em nuvem que está quebrado silenciosamente há meses.

E se os números de armazenamento do seu Mac não baterem por alguns gigabytes em vez de noventa, relaxe. Isso é só o APFS sendo APFS, e a aritmética de Howard Oakley explica tudo isso.

Leitura relacionada: Dados do Sistema ocupando espaço enorme no Mac e não encolhem · Gerenciamento e otimização de armazenamento do macOS · Comparativo de analisadores de armazenamento para Mac · Guia completo do iCloud Drive · Atualização do macOS travada: espaço insuficiente

Fontes: Michael Tsai, "Huge RTCReporting Logs and Dropbox", 21 de agosto de 2026 · The Eclectic Light Company, "The arithmetic of free space", 21 de agosto de 2026 · Thread 254838127 da Comunidade de Suporte da Apple (RTCReporting) · Apple, Ajuda do Disk Utility (espaço purgável) · Verificação local no macOS 26.5.2 (build 25F84), 22 de agosto de 2026, usando ls, plutil, strings, df e ps.