¿El disco de tu Mac está lleno sin motivo aparente? Revisa la carpeta de logs de root

Aquí tienes un problema de almacenamiento que derrota a casi cualquier herramienta a la que la gente recurre primero.

Tu Mac dice que el disco está casi lleno. Abres un analizador de almacenamiento y sumas lo que encontró — y el total llega a decenas de gigabytes menos de lo que macOS dice que está en uso. Disk Utility no reporta snapshots. Borras apps, descargas fotos, vacías la Papelera, y el número apenas se mueve. Reiniciar ayuda durante una hora, y luego el espacio vuelve a desaparecer.

Los archivos son reales. Tus herramientas no pueden verlos porque viven en /private/var/root — el directorio de inicio de la cuenta root — y cada una de esas herramientas se está ejecutando como tú.

En los Macs donde esto golpea más fuerte, la mayor parte es una sola cosa: archivos de log escritos por un daemon del sistema llamado rtcreportingd, en cantidades que llegan a decenas de gigabytes. Michael Tsai documentó un caso el 21 de agosto de 2026 donde /private/var/root/Library/Logs por sí solo consumía 74 GB en una MacBook Air M4, y donde la carpeta volvió a subir a 27 GB en un solo día después de haber sido vaciada.

Los logs no son la enfermedad. Son el aspecto que tiene un daemon atascado cuando nadie está leyendo el termómetro. Este artículo cubre cómo encontrar el espacio, cómo recuperarlo sin cometer el error clásico que desperdicia todo el esfuerzo, y cómo encontrar el proceso que realmente lo está generando.

Puntos clave

• /private/var/root es invisible para cualquier cosa que se ejecute como tu usuario. Confirmamos en macOS 26.5.2 que ls /private/var/root devuelve Permission denied. Los analizadores de almacenamiento, el Finder y las cifras de uso de Disk Utility se pierden todo lo que hay dentro.
• rtcreportingd es un daemon real del sistema de Apple que se ejecuta como root. Verificamos que su tarea de launchd declara UserName => root, que es exactamente la razón por la que sus logs terminan en el directorio de inicio de root y no en el tuyo.
• Los tamaños reportados llegan a decenas de gigabytes, y vuelven a crecer rápido. 74 GB en un caso documentado, de vuelta a 27 GB en un día tras borrarlos, porque la causa subyacente seguía ejecutándose.
• El error clásico desperdicia todo el trabajo. Borrar archivos con una herramienta gráfica que se ejecuta bajo sudo los mueve a la Papelera de root. El espacio no se recupera. Hay que borrar de forma inmediata, o vaciar la Papelera de root.
• Busca un cliente de sincronización atascado. En el caso documentado, rtcreportingd y fileproviderd estaban ambos clavados cerca del 100% de CPU, y cerrar Dropbox detuvo a los dos. fileproviderd es el proceso de macOS que aloja las extensiones de File Provider para almacenamiento en la nube.
• No borres cosas en /private/var/root al azar. Los logs y las cachés son seguros de eliminar. Otras cosas ahí no lo son, y este artículo es específico sobre cuál es cuál.

Por qué tus herramientas de almacenamiento no pueden verlo

Antes de la solución, el mecanismo — porque entenderlo es lo que te evita perseguir la pista equivocada la próxima vez.

Root tiene un directorio de inicio, y los daemons lo usan

En macOS, el directorio de inicio de la cuenta root es /private/var/root. La mayoría asume que está esencialmente vacío y que solo se toca al ejecutar Terminal desde macOS Recovery. Eso no ha sido cierto desde hace años. Los daemons del sistema que se ejecutan como root y quieren almacenar estado, cachés o logs los escriben ahí, con la misma estructura de Library que usa tu propio directorio de inicio:

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

Puedes confirmar que el directorio está fuera de tu alcance con un solo comando. En un Mac donde Terminal no tiene privilegios elevados:

ls /private/var/root

Ejecutamos exactamente esto en macOS 26.5.2 (build 25F84) y obtuvimos:

ls: /private/var/root: Permission denied

Eso es una simple denegación de permisos de Unix — el directorio de inicio de root está restringido por modo a root. No es una protección de privacidad de TCC y no es algo que Acceso total al disco (Full Disk Access) resuelva. Un analizador de almacenamiento que lanzaste desde el Dock se ejecuta como tú, así que recorre el sistema de archivos como tú, y todo lo que hay bajo ese directorio es un agujero en su mapa.

Por eso los números no coinciden

El síntoma que la gente describe es «los totales de mi herramienta de almacenamiento no cuadran», y esta es la razón. En el caso documentado, los totales por carpeta de OmniDiskSweeper llegaban a aproximadamente 90 GB menos de lo que macOS reportaba como usado.

Vale la pena separar esto de las otras razones por las que los números de espacio libre de un Mac no coinciden, porque hay varias y solo una de ellas es este bug.

Howard Oakley expuso la aritmética general el 21 de agosto de 2026, y los números de su propia Mac mini ilustran el punto:

Fuente	Reportado como usado en el mismo volumen
Diferencia del contenedor en diskutil apfs list	837.101 GB
Suma de la Capacidad Consumida por volumen	837.027 GB
Obtener información del volumen en Finder	826.67 GB
Disk Utility	814.03 GB

Cuatro herramientas, cuatro números, una diferencia de unos 23 GB, y nada mal. Las diferencias vienen de la contabilidad contenedor-versus-volumen, del espacio purgable y del comportamiento de archivos especiales de APFS:

• Contenedor versus volumen. Un contenedor APFS aloja varios volúmenes que comparten espacio libre. «Espacio libre en Macintosh HD» y «espacio libre en el contenedor» son preguntas distintas con respuestas distintas.
• Espacio purgable. macOS marca cierto contenido como eliminable bajo demanda — cachés, algunos snapshots, algún contenido descargado. El propio libro de Ayuda de Disk Utility dice: «no puedes eliminar manualmente los archivos designados como purgables, pero macOS los elimina conforme se necesita espacio». Oakley midió 47.04 GB purgables en su volumen de Data.
• Archivos especiales. Los archivos clon de APFS comparten almacenamiento hasta que divergen; los archivos dispersos (sparse) solo almacenan sus datos no nulos; algunos archivos del sistema están comprimidos; los archivos sin datos locales (dataless) mantienen sus datos en la nube y se materializan bajo demanda. La contabilidad de espacio libre usa lo que hay en disco ahora mismo.

Nada de eso produce una brecha persistente, creciente e inexplicada de 90 GB. Si tu brecha es pequeña y estable, es contabilidad normal. Si es grande y crece mientras el Mac está inactivo, algo está escribiendo archivos que no puedes ver.

Para las confusiones de almacenamiento más comunes — Datos del sistema que no se reducen, snapshots que no se liberan — las cubrimos por separado en Datos del sistema ocupando mucho espacio en Mac y en la guía de gestión de almacenamiento de macOS. Revisa eso primero. Este artículo trata sobre el caso en que esas explicaciones no encajan.

Qué es en realidad rtcreportingd

Seamos honestos sobre los límites aquí, porque internet está a punto de llenarse de explicaciones confiadas sobre un daemon que Apple nunca ha documentado.

Lo que verificamos directamente, en macOS 26.5.2 (build 25F84):

El ejecutable existe en /usr/libexec/rtcreportingd y pesa unos 1.45 MB. Su tarea de launchd está en /System/Library/LaunchDaemons/com.apple.rtcreportingd.plist, y dice:

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

Compruébalo en tu propio Mac — el plist se puede leer sin restricciones:

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

UserName => root es toda la explicación de a dónde van los logs. Un daemon que se ejecuta como root y escribe en ~/Library/Logs escribe en /private/var/root/Library/Logs. No hay nada exótico en ello.

El binario está escrito en Swift, y los nombres de sus clases internas son visibles con strings. Incluyen BackendHTTP, TransparencyLog, StorebagCache, StorebagCoordinator, SessionCoordinator, XPCActivity y — fíjate en este — CacheCleanupActivity. Los nombres de sus servicios Mach incluyen com.apple.rtcreporting, com.apple.rtcreporting.pathmonitor y com.apple.rtcreportingd.storebag.

Lo que no vamos a decirte es qué significan las siglas «RTC» ni exactamente sobre qué reporta el daemon. Apple no lo documenta, y no vamos a inventar el desarrollo de un acrónimo y presentarlo como un hecho. Lo que respaldan los nombres de clases es una descripción modesta: es un servicio de reporte o telemetría que habla con un backend de Apple por HTTP, cachea estado localmente, monitorea la disponibilidad de rutas de red, y tiene una actividad programada para limpiar su propia caché.

Ese último detalle es el interesante. El daemon tiene lógica de limpieza. Cuando sus logs crecen a decenas de gigabytes, la lectura razonable no es «Apple olvidó rotar los logs» sino «algo está generando eventos más rápido de lo que el daemon puede procesarlos y limpiarlos después». Lo cual apunta a lo que sea que esté generando los eventos.

Para ser claros sobre el límite: eso es una inferencia a partir de nombres de clases, no una declaración sobre la implementación de Apple. Trátalo como una hipótesis que resulta encajar con el comportamiento observado.

Encontrar el espacio

Necesitas sudo para todo esto, y deberías leer cada comando antes de ejecutarlo.

1. Confirma que la brecha existe

Primero, lo que macOS cree que está en uso:

df -h / /System/Volumes/Data

En un Mac moderno obtienes dos líneas, porque el volumen del sistema es un snapshot sellado de solo lectura y tus datos viven en un volumen separado dentro del mismo contenedor. En nuestro Mac de prueba:

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

Fíjate en que ambas líneas reportan el mismo Size y Avail — eso es el espacio libre compartido del contenedor, no una cuota por volumen. Esta es la distinción contenedor-versus-volumen de antes, hecha concreta.

Luego revisa los snapshots, para poder descartarlos:

diskutil apfs listSnapshots /System/Volumes/Data

Y la vista del contenedor:

diskutil apfs list

Si los snapshots son mínimos y la Capacidad En Uso del contenedor está muy por encima de lo que encontró tu analizador de almacenamiento, tienes un problema de archivos invisibles.

2. Mide el directorio de inicio de root

Este es el comando que lo encuentra:

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

-d 2 limita la profundidad a dos niveles, lo cual es suficiente para ver si Library/Logs o Library/Caches es el culpable sin esperar un recorrido completo. Espera que tarde uno o dos minutos en una máquina con un ofensor grande.

Para una vista ordenada de los peores ofensores un nivel más abajo:

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

En un Mac sano estos totales son pequeños — megabytes, no gigabytes. Si /private/var/root/Library/Logs devuelve un número con «G» al final y más de un dígito por delante, ese es tu espacio desaparecido.

3. Mira qué hay dentro

Antes de borrar nada, mira:

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

En el caso documentado, el contenido era «casi enteramente de RTCReporting». Si el tuyo está dominado por otra cosa, eso cambia lo que deberías hacer — el enfoque diagnóstico de este artículo sigue aplicando, pero el culpable será un subsistema distinto.

4. Una alternativa gráfica

Si prefieres ver esto en una ventana, OmniDiskSweeper es gratis y es lo que sacó a la luz el problema en el reporte original. Lo importante es que debes relanzarlo con privilegios elevados para que pueda ver el directorio de inicio de root. Lanzado normalmente te mostrará la misma imagen incompleta que todo lo demás.

Nuestro resumen de analizadores de almacenamiento cubre las opciones, pero ten en cuenta que la misma limitación aplica a todas: si la herramienta no se ejecuta como root, este espacio le es invisible.

Recuperarlo — y el error que desperdicia todo el trabajo

Aquí está la trampa, y es una buena.

Si borras estos archivos con una herramienta gráfica que se ejecuta bajo sudo, la herramienta hace lo que siempre hace: los mueve a la Papelera. Pero como el proceso se ejecuta como root, esa es la Papelera de root, en /private/var/root/.Trash, que no aparece en tu Dock y que nunca se te ocurrirá vaciar. Los archivos siguen en el disco. Tu espacio libre no cambia. Concluyes que el borrado no funcionó.

En OmniDiskSweeper específicamente, mantén presionada la tecla Option para convertir Delete en Delete Immediately.

Desde Terminal, borra el contenido de los logs directamente:

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

Lee ese comando antes de ejecutarlo. Elimina el contenido del directorio Logs de root y nada más. No acortes la ruta. No añadas un espacio antes de la barra.

Luego revisa si hay algo esperando en la Papelera de root de un intento anterior:

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

Y si lo hay:

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

Las cachés en el directorio de inicio de root también son generalmente seguras de vaciar — son, por definición, regenerables:

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

Qué no tocar. No borres /private/var/root en sí. No borres /private/var/root/Library por completo. No te pongas a quitar keychains, preferencias, o cualquier cosa que no reconozcas. Los logs y las cachés son las categorías seguras; todo lo demás ahí pertenece a un componente del sistema que lo puso ahí por una razón.

Reinicia después. Luego vuelve a comprobar con df -h para confirmar que el espacio realmente volvió.

Ahora encuentra qué lo está causando

Si te detienes en el borrado, el espacio vuelve y luego se va otra vez. En el caso documentado volvió a 5 GB a los pocos minutos de un reinicio y a 27 GB en un día.

Vigila la CPU

Abre Activity Monitor, ordena por % CPU, y busca dos procesos:

• rtcreportingd — el daemon que escribe los logs
• fileproviderd — el proceso de macOS que aloja las extensiones de File Provider para almacenamiento en la nube

En el caso documentado, ambos estaban clavados cerca del 100% de CPU de forma continua, con el Mac inactivo.

Desde Terminal:

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

Ambos procesos existen y se ejecutan en cualquier Mac sano — confirmamos que los dos corrían en nuestra máquina de prueba, que no tiene ningún problema de almacenamiento. Su presencia es normal. Su uso sostenido de CPU no lo es. Un pequeño porcentaje mientras hay una sincronización en curso es esperable. Quedarse en 90–100% con el Mac sin tocar es la señal.

Vigila cómo crecen los logs

La confirmación más directa es medir dos veces:

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

Espera diez minutos con el Mac inactivo, y ejecútalo de nuevo. En un Mac sano el número no se mueve de forma significativa. Si sube de manera medible mientras no haces nada, algo está en un bucle.

Sospecha primero de la sincronización en la nube

fileproviderd es la pista delatora. Es el proceso del sistema que aloja las extensiones de File Provider — el mecanismo moderno que usan Dropbox, OneDrive, Google Drive, Box e iCloud Drive para presentar archivos en la nube dentro del Finder. Si está quemando CPU de forma continua, una de esas extensiones está atascada.

En el caso documentado, el cliente era Dropbox, en un Mac donde llevaba comportándose mal desde hacía cerca de un año — no mantenía los archivos sin conexión como estaba configurado, y parecía sincronizar constantemente aunque nada hubiera cambiado. Cerrar Dropbox detuvo tanto el uso de CPU como el crecimiento de los logs de inmediato.

Para probar esto en tu propio Mac, cierra tus clientes de sincronización uno por uno y observa. Cierra el cliente por completo — icono en la barra de menú, Salir — en lugar de pausar la sincronización, porque una extensión pausada puede seguir cargada.

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

Si cerrar un cliente hace que ambos procesos bajen a inactividad, lo has encontrado.

Qué hacer con el cliente de sincronización

Opciones, más o menos en orden de esfuerzo:

1. Actualízalo. Los bugs en extensiones de File Provider son comunes y se corrigen con frecuencia. Comprueba si hay una actualización antes que nada.
2. Cierra sesión y vuelve a entrar. Esto reconstruye el estado local de la extensión y resuelve un número sorprendente de casos de sincronización atascada.
3. Quita y reinstala el cliente. Más disruptivo pero más a fondo.
4. Muda los datos a otro lugar. En el caso documentado, el resultado fue migrar a iCloud Drive, después de que Dropbox demostrara no ser capaz de descargar los archivos de forma fiable para la migración — el autor terminó descargando la carpeta desde la interfaz web de Dropbox en su lugar. Luego iCloud Drive «subió todo rápidamente y se asentó en un estado de nulo uso de CPU».

Ese último punto vale la pena señalarlo con honestidad: migrar entre proveedores de nube cuando el cliente de origen está roto es realmente doloroso, y la interfaz web puede ser tu vía de exportación más fiable. Nuestra guía de iCloud Drive cubre el lado del destino, y si iCloud Drive mismo se está comportando mal, el bug de descarga automática de iCloud Drive es un problema conocido aparte.

No decimos que Dropbox sea el único culpable posible. Es el cliente en el caso documentado. Cualquier extensión de File Provider puede quedar atascada, y el diagnóstico es el mismo sin importar cuál uses.

Los otros lugares donde se esconde el almacenamiento

El directorio de inicio de root es el que casi nadie revisa, pero no es el único lugar donde una herramienta a nivel de usuario se queda corta. Si tu brecha no está en /private/var/root, repasa lo siguiente antes de concluir que los números mienten.

Datos propiedad de otros daemons, en manos de root. /private/var/root es donde vive el directorio de inicio de root, pero los componentes del sistema también escriben bajo /private/var/db, /private/var/folders y /Library/Logs. Mídelos de la misma manera:

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 alberga contenedores temporales y de caché por usuario y puede llegar legítimamente a varios gigabytes. Está gestionado por macOS y en general debería dejarse en paz; un reinicio limpia las partes volátiles.

Snapshots locales de Time Machine. Estos son la causa más señalada y la que menos veces resulta culpable en realidad. Compruébalo en lugar de asumirlo:

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

Si los snapshots realmente son el problema, macOS los reduce automáticamente bajo presión de espacio, y los casos más profundos están cubiertos en nuestra guía de resolución de problemas de Time Machine.

Los directorios de inicio de otros usuarios. Obvio una vez que se dice, invisible en la práctica — una segunda cuenta en el Mac con 200 GB de vídeo no es algo que tu herramienta de almacenamiento te muestre mientras se ejecuta como tú. sudo du -h -d 1 /Users lo responde en una línea.

Archivos retenidos por un proceso en ejecución. Espacio que se borró pero no se liberó, porque un proceso sigue teniendo abierto el descriptor de archivo. Esto se manifiesta como una brecha que desaparece tras un reinicio:

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

El almacén local de Mail, las copias de seguridad de dispositivos iOS, y Xcode. Los tres directorios clásicos, grandes y olvidados, en el Mac de un desarrollador o de un usuario intensivo de 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 estos son legibles como tu propio usuario, así que un analizador de almacenamiento sí los encontrará — simplemente se pierden en una lista larga. Vale la pena revisarlos antes de escalar a sudo.

Archivos marcador de la nube que se materializaron. Si usas una opción de «mantener archivos solo en línea» en cualquier cliente de sincronización, un bug o una búsqueda de texto completo puede descargar todo silenciosamente. Esa es la misma clase de fallo que la de este artículo y normalmente aparece como un crecimiento constante en la propia carpeta de sincronización.

¿Qué tan común es esto?

Respuesta honesta: no lo sabemos, y tampoco lo sabe nadie más que publique sobre ello.

Lo que existe en el registro público es un testimonio de primera mano con números y una solución específicos, un hilo de la Comunidad de Soporte de Apple sobre el almacenamiento de RTCReporting, y un hilo de Reddit de usuarios preguntando qué estaba ocupando su almacenamiento. Eso basta para establecer que el problema es real y reproducible, y no basta para decir qué proporción de Macs se ven afectados.

Lo que sí podemos decir a partir de nuestra propia comprobación: rtcreportingd se ejecuta en un Mac de fábrica sin ningún problema de almacenamiento, sus logs ahí son insignificantes, y el daemon tiene lógica de limpieza que evidentemente funciona la mayor parte del tiempo. Este es un modo de fallo, no un comportamiento por defecto. Si las cuentas de almacenamiento de tu Mac cuadran, no tienes nada que arreglar.

Apple no ha publicado ningún documento de soporte sobre esto, no lo ha reconocido, y no ha lanzado una solución documentada. Si te ocurre, reportarlo a Apple mediante feedback vale la pena los cinco minutos que toma — un problema no reconocido sigue sin reconocerse.

Solución de problemas comunes

sudo du tarda una eternidad

Eso es normal en un árbol de directorios grande o muy fragmentado. Usa -d 1 primero para encontrar qué carpeta de nivel superior es grande, y luego desciende solo a esa. Evita ejecutar du sobre todo el disco cuando ya sabes qué directorio te interesa.

Borré los logs pero el espacio libre no cambió

El problema de la Papelera. Revisa sudo du -sh /private/var/root/.Trash y vacíala con sudo rm -rf /private/var/root/.Trash/*. Esto atrapa a casi todos los que usaron una herramienta gráfica.

La segunda posibilidad es que un proceso todavía tenga los archivos borrados abiertos, en cuyo caso el espacio no se libera hasta que el proceso termina. Reinicia el Mac y comprueba de nuevo.

El espacio volvió en un día

Es lo esperado, si no has encontrado la causa. Borrar los logs trata el síntoma. Ve al paso de Activity Monitor y encuentra qué está en bucle.

rtcreportingd está usando CPU pero no tengo clientes de sincronización en la nube

Entonces el desencadenante es otra cosa. Ordena Activity Monitor por CPU y mira qué más está ocupado. Revisa el log unificado en busca de la actividad propia del daemon:

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

Ten en cuenta que las consultas del log unificado solo devuelven lo que realmente se escribió, y los datos del log caducan — una consulta sobre una ventana larga puede legítimamente devolver nada.

First Aid de Disk Utility dice que el disco está bien

Lo dirá. Esto no es corrupción del sistema de archivos. First Aid revisa la consistencia de los metadatos; un directorio lleno de archivos grandes y válidos es perfectamente consistente.

¿Puedo simplemente desactivar rtcreportingd?

No lo haríamos. Es un daemon del sistema de Apple en un Mac con System Integrity Protection, y desactivar daemons de lanzamiento del sistema para sortear un síntoma tiende a producir un segundo problema, menos evidente, más adelante. Arregla el proceso que lo está impulsando en su lugar. Si el daemon se comporta mal sin un desencadenante identificable, eso es un bug de Apple que vale la pena reportar, no uno para rodear.

Mi Mac se está quedando sin espacio y necesito espacio ahora

Ganancias inmediatas y seguras mientras diagnosticas: vacía tu propia Papelera, vacía la Papelera de root como se explicó antes, borra el contenido de los Logs de root, y revisa sudo du -h -d 1 /private/var/root/Library/Caches. Entre todo eso a menudo se libera suficiente para hacer el Mac utilizable de nuevo mientras encuentras la causa. Nuestra guía sobre fallos de actualización causados por espacio insuficiente cubre qué hacer si esto está bloqueando específicamente una actualización de macOS.

Preguntas frecuentes

¿Qué es /private/var/root?

Es el directorio de inicio de la cuenta root en macOS. Solo root puede leerlo, razón por la cual las herramientas que se ejecutan como tu usuario no pueden ver dentro. Los daemons del sistema que se ejecutan como root almacenan ahí logs, cachés y estado, usando la misma estructura de Library que tu propio directorio de inicio.

¿Por qué el Finder o mi app de almacenamiento no pueden ver estos archivos?

Porque se ejecutan como tú, y los permisos Unix del directorio excluyen a tu usuario. Esto no es una protección de privacidad que Acceso total al disco pueda levantar — son permisos de archivos ordinarios. Una herramienta gráfica debe relanzarse con privilegios elevados para poder recorrer ese directorio.

¿Qué es rtcreportingd?

Un daemon del sistema de Apple en /usr/libexec/rtcreportingd, lanzado por com.apple.rtcreportingd y ejecutándose como root. Apple no lo documenta. Su estructura interna indica un servicio de reporte que se comunica con un backend de Apple por HTTP y mantiene una caché local. Existe en Macs sanos y no es en sí mismo un problema.

¿Es malware?

No. Es un binario de Apple en /usr/libexec, lanzado por un daemon de lanzamiento dentro del volumen del sistema sellado. Puedes confirmar su firma:

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

¿Cuánto espacio es normal para la carpeta Logs de root?

En un Mac sano, poco — esta no es una carpeta que deberías poder notar. Si sudo du -sh /private/var/root/Library/Logs devuelve algo en gigabytes de dos dígitos, ese es el problema. No hay un umbral oficial de Apple; la prueba práctica es si crece mientras el Mac está inactivo.

¿Una app de limpieza para Mac arreglaría esto?

Casi con toda seguridad no, por la misma razón que tu analizador de almacenamiento se lo perdió: a menos que el limpiador escale privilegios y recorra específicamente el directorio de inicio de root, no puede ver los archivos. E incluso un limpiador que los eliminara no impediría que volvieran, porque la causa es un proceso en bucle, no basura acumulada.

¿Esto afecta solo a ciertos Macs o versiones de macOS?

No hay suficientes datos públicos para saberlo. El caso documentado fue una MacBook Air M4. Verificamos el daemon y el comportamiento de permisos en macOS 26.5.2. Nada en el mecanismo es específico de un chip o de una versión de macOS — root ha tenido un directorio de inicio desde que macOS existe.

¿Debería reportar esto a Apple?

Sí, si te ocurre. Incluye la salida de sudo du -h -d 2 /private/var/root/, las cifras de CPU de rtcreportingd y fileproviderd, y qué cliente de sincronización resolvió el problema al detenerse. Apple no ha publicado nada sobre esto, y los reportes específicos son lo que hace que eso cambie.

Conclusión

La razón por la que este problema es tan frustrante es que cada instinto que tienes sobre el almacenamiento de un Mac es incorrecto para él. Los archivos no están en una carpeta que puedas encontrar. No son snapshots. No son Datos del sistema en el sentido que el panel de Almacenamiento entiende. Borrar apps no ayuda, los números no cuadran, y la única herramienta que te lo mostraría es la que no se te ocurrió ejecutar con sudo.

Una vez que sabes dónde mirar, es un trabajo de diez minutos: mide /private/var/root con du, borra los logs, vacía la Papelera de root, y luego — la parte que realmente importa — vigila Activity Monitor hasta encontrar el proceso que los está volviendo a llenar. Nueve de cada diez veces, dado fileproviderd junto a rtcreportingd en la lista de CPU, se trata de un cliente de sincronización en la nube que llevaba meses averiado en silencio.

Y si los números de almacenamiento de tu Mac no coinciden por unos pocos gigabytes en lugar de noventa, relájate. Eso es simplemente APFS siendo APFS, y la aritmética de Howard Oakley lo explica todo.

Lectura relacionada: Datos del sistema ocupando mucho espacio en Mac y sin reducirse · Gestión y optimización del almacenamiento de macOS · Comparativa de herramientas de análisis de almacenamiento para Mac · Guía completa de iCloud Drive · Actualización de macOS atascada: espacio insuficiente

Fuentes: 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 · Hilo 254838127 de la Comunidad de Soporte de Apple (RTCReporting) · Apple, Ayuda de Disk Utility (espacio purgable) · Verificación local en macOS 26.5.2 (build 25F84), 22 de agosto de 2026, usando ls, plutil, strings, df, y ps.