- El volumen de arranque de una MacBook Pro M2 se llenó tanto durante la descarga de juegos de Steam que solo quedaron 41 KB, dejando a macOS en un estado en el que ni siquiera podía borrar archivos
- Vaciar la papelera desde Finder, usar
rmyfind -exec rmen Terminal, e incluso eliminar snapshots de Time Machine desde Disk Utility falló en todos los casos con errores del tipo “No space left on device” - Tras reiniciar, el arranque también se detenía a la mitad, y ni siquiera al montarlo en otra Mac mediante recoveryOS y Share Disk en Apple silicon fue posible forzar el borrado
- Después de formatear la unidad e intentar reinstalar macOS y restaurar con Time Machine, se encadenaron más problemas: una restauración de Ventura interrumpida, diferencias de versión entre Sonoma 14.4 y la 14.3.1 anterior, y fallas al montar recursos de red SMB/Samba
- Al final, se copió la imagen de disco más reciente de Time Machine a un SSD externo de 1 TB para recuperar manualmente archivos del directorio personal y apps; cuando se combinan falta total de espacio y fallas de restauración, incluso para usuarios avanzados es difícil reaccionar
Una Mac donde ni borrar archivos era posible por falta de espacio
- El almacenamiento de una MacBook Pro M2 se llenó mientras descargaba desde Steam un juego comprado legalmente
- Aunque la unidad ya estaba peligrosamente llena, macOS no detuvo la gran descarga de Steam, y en el volumen de arranque quedaron apenas 41 KB
- La mayoría de los archivos importantes estaban en la nube, y no era una situación en la que hubiera que preservar sí o sí archivos locales grandes
- El problema no era solo la falta de espacio, sino que el sistema operativo había quedado en un estado donde no podía borrar archivos de ninguna manera
Causa sospechada: descarga de Steam y snapshots locales de Time Machine
- Es posible que, con una conexión gigabit a internet y archivos grandes de Steam, macOS no haya logrado controlar el aumento del uso de almacenamiento
- También se sospecha que macOS estaba creando snapshots locales de Time Machine al mismo tiempo
- macOS mantiene snapshots para ofrecer respaldos locales de las últimas 24 horas incluso cuando hace copias hacia un destino de Time Machine externo o en red
- Los archivos de Steam parecían externamente un único archivo gigantesco, pero es posible que desde la perspectiva de Time Machine se manejaran de otra forma
- Puede que haya habido un conflicto entre el archivo real local y snapshots creados de forma especial, aunque la causa exacta no está confirmada
Todos los intentos de borrado fallaron
- Vaciar la papelera en Finder falló desde
File > Empty Trash- El mensaje de error fue “The operation can’t be completed because the disk is full”
- Terminal sí abría, pero el comando estándar de Unix
rmno funcionaba- El mensaje de error era “No space left on device”
- También falló una alternativa basada en
find, que localizaba archivos grandes y ejecutabarmcon la opción-exec
- En Disk Utility también se intentó seleccionar y borrar snapshots de Time Machine del volumen de arranque APFS, pero se topó con la misma limitación
- En general, los snapshots solo ocupan el espacio necesario para las diferencias respecto del snapshot anterior
- Incluso en este caso apareció el error “no space left”
Reinicio, recoveryOS y Share Disk tampoco sirvieron
- Se reinició esperando limpiar cachés, pero la Mac ya no volvió a arrancar normalmente
- Repetidamente fallaba después de que la barra de progreso llegara más o menos a la mitad
- Desde recoveryOS se intentó reparar con Disk Utility y hacer tareas relacionadas con reinstalación, dejando sin montar el volumen de arranque, pero los comandos de Terminal daban el mismo error
- Se intentó montar la unidad en otra Mac con la función Share Disk de Apple silicon
- Se quiso forzar el borrado mediante compartición de disco basada en Samba, pero también falló
Problemas continuos durante la restauración con Time Machine
- Había respaldos de Time Machine, incluido uno de la noche anterior, y como la mayoría de los datos importantes estaban en la nube, no era una situación de obsesionarse con una recuperación perfecta
- Primero se borró la unidad y se reinstaló con macOS Recovery el sistema original de fábrica de la MacBook Pro: Ventura
- Al iniciar macOS, se accedió al respaldo de Time Machine en red mediante Migration Assistant, desmarcando algunos elementos de restauración para dejar suficiente espacio libre
- Durante la restauración, Ventura se quedó detenido a mitad del proceso y luego no reanudó
- Después se actualizó la Mac a Sonoma, que era el macOS que se usaba en ese momento
- La actualización fue exitosa, pero la versión instalada era 14.4
- La Mac original tenía instalada la 14.3.1
- Al intentar restaurar directamente en la fase de arranque, la diferencia de versiones hizo que no se permitiera
Problema de montaje de Time Machine en red en Sonoma 14.4
- Se creó una cuenta básica de usuario en Sonoma y luego se ejecutó Migration Assistant
- Migration Assistant encontraba y reconocía la Mac en red que administraba el respaldo de Time Machine
- Sin embargo, no podía montar el volumen de respaldo del hijo y repetidamente mostraba “Mount failed”
- Al buscar en foros, parecía que en Sonoma el procedimiento de montaje de red basado en SMB/Samba estaba roto para restauraciones de Time Machine, sin que hubiera una solución clara
- Todo indicaba que este problema seguía presente incluso en macOS 14.4
Recuperación final: copiar el respaldo a un SSD externo y migrar manualmente
- Se abandonó la restauración completa con Migration Assistant y solo se recuperaron manualmente las apps y archivos necesarios
- En la Mac que administraba el respaldo en red, se hizo doble clic en la imagen de disco de esa computadora y se ingresó la contraseña del volumen de Time Machine
- En ese volumen de Time Machine en red siempre se había configurado una contraseña separada
- Se localizó el ícono de disco con la marca de tiempo más reciente y se copió a un SSD externo de 1 TB vacío
- Luego se conectó el SSD externo a la cuenta temporal de la MacBook Pro para trasladar los archivos necesarios
- Incluía la mayor parte del contenido de la carpeta del directorio personal
- Se excluyeron archivos de descargas grandes y algunos videos innecesarios
- Se decidió conservar el SSD externo por un tiempo para poder recuperar archivos adicionales si aparecía algo faltante
Alternativas que no se pudieron intentar
- Se podía haber desmontado la unidad de Time Machine para respaldo en red desde la Mac que la administraba y luego conectarla directamente a la Mac del hijo
- En ese caso, posiblemente habría aparecido como punto de origen para Migration Assistant
- También se podía haber copiado el disco virtual desde la imagen de disco de Time Machine ya montada para que el SSD externo de 1 TB pareciera el volumen fuente de la Mac
- No se comprobó si este método realmente habría funcionado
- Si hubiera resultado, podría haber permitido una restauración directa con Migration Assistant
- Como ya se habían acumulado horas de trabajo y más de un día de intentos, y la persona usuaria no necesitaba especialmente una recuperación perfecta a nivel de directorios, no se hicieron más experimentos
1 comentarios
Opiniones de Hacker News
Quizá al autor le habría ido mejor si hubiera arrancado la Mac desde un dispositivo de almacenamiento externo y luego borrado archivos innecesarios del disco interno: Use an external storage device as a Mac startup disk
Me sorprendió que, en las Mac con Apple Silicon, no todos los puertos sean equivalentes al arrancar desde un disco externo.
Al instalar macOS en un dispositivo de almacenamiento, en las notebooks Mac hay que evitar el puerto USB-C más a la izquierda entre los puertos del lado izquierdo, y en las iMac/Mac mini/Mac Studio/Mac Pro también hay puertos USB-C específicos que se deben evitar según el modelo.
Dicen que, una vez terminada la instalación, se puede conectar a cualquier puerto.
El autor arrancó desde recoveryOS, que está en una partición separada, e intentó borrar archivos de la partición principal del sistema, pero
rmfalló con el mismo errorNo space left on device.Por eso, como dijeron otros, tal vez habría funcionado truncar el archivo con
echo -n >file.Especulando con un poco de conocimiento sobre la estructura de discos HFS+, parece que el archivo de journal también se llenó y, como borrar requiere escribir en el journal y a veces expandirlo, quedó en una situación extraña en la que el borrado mismo requiere más espacio, aunque sea temporalmente.
macOS siguió escribiendo archivos hasta que solo quedaron 41 KB en la unidad.
Alguna vez llené por accidente NTFS y FAT32 hasta 0 bytes, y aun así era posible borrar cosas.
Revisando foros, parece que Sonoma rompió el procedimiento de montaje de red basado en SMB/Samba para restauraciones de Time Machine, y en 14.4 todavía no parece haber una solución.
Por experiencia, SMB se volvió poco confiable y demasiado lleno de bugs desde alrededor de 10.12~10.13, y ahora parece que a Apple ya ni siquiera le importa si esto funciona.
No quiero imaginar qué haría alguien sin décadas de experiencia con Mac al encontrarse con esta cadena de fallas del sistema.
No tengo décadas de experiencia con Mac, pero en una situación así primero habría intentado
fsck; se me hace raro que no se mencione aquí.Si no pudiera copiar el contenido del disco a otro disco, formatear y devolverlo, probablemente miraría la documentación de APFS (https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf) y trataría de encontrar, con
ddy un editor hexadecimal, qué habría que modificar para liberar espacio.Después, la recolección de basura encuentra los archivos que ya no pertenecen al árbol activo y devuelve ese espacio al almacenamiento.
Normalmente los cambios se agrupan para mantener manejable la cantidad de modificaciones del árbol, y gracias a este diseño las snapshots del sistema de archivos pasan a ser otra referencia a un árbol determinado.
Este proceso requiere espacio, pero los sistemas de archivos CoW suelen reservar almacenamiento de emergencia por este motivo.
Hace unos años, en una Hackintosh conectada por 10GbE a un NAS grande, medí con BlackMagic Disk Speed Test: SMB en Windows daba 900 MB/s, SMB en macOS 200 MB/s, y NFS y AFP en macOS daban ambos 1000 MB/s.
Las funciones de macOS relacionadas con trabajo profesional, lamentablemente, son ridículas.
Dicen que AFP está muerto, pero en mi Mac Pro sigue funcionando muy bien como cliente, y su rendimiento es tan superior al de SMB que casi parece una comedia.
Si los llenas por completo, pueden aparecer problemas.
BTRFS intenta pasar a modo de solo lectura cuando todavía queda espacio de metadatos, lo que permite volver a montarlo en modo seguro y borrar algo, pero no es una protección perfecta.
Hasta donde sé, NTFS y FAT32 no son sistemas de archivos con journaling.
Me pasó algo así en mi primer trabajo.
Por error llené un clúster con archivos de jobs, y el administrador del sistema empezó a mandarme correos para que lo arreglara rápido, pero
rmno funcionaba.Ahí aprendí que, incluso cuando no se puede borrar, truncar un archivo normalmente sí se puede; por eso, cuando
rm foono funciona, muchas veces sirve usarcat /dev/null > foo.:>filepathsuele funcionar.Aunque algunos sistemas de archivos quizá ni siquiera permitan eso.
En esos casos hay que esperar que el sistema de archivos soporte ampliar tamaño, reducir tamaño o agregar almacenamiento temporal extra, o que el subsistema subyacente permita agregar/quitar almacenamiento de respaldo.
Puede que también haga falta un comando aparte para volver a una estructura de un solo dispositivo de bloques, como en btrfs.
Así que hice que el proceso de backup enviara periódicamente datos basura directamente a /dev/null, y probablemente ese hack sucio todavía siga corriendo.
/dev/nulles mágico y vale la pena leer sobre él.>file.Los formatos de sistemas de archivos del siglo XXI son mucho más complejos que UFS, y funciones como snapshots y journaling crean nuevas formas en que el sistema de archivos puede quedar en interbloqueo consigo mismo.
Al final tuve que recuperarlo con
truncate.Sabía que ZFS era mejor para este tipo de situaciones, pero igual sentí esa sensación de hundimiento de “ah… maldita sea” cuando sabes que de verdad la regaste.
Time Machine parece empeorar constantemente.
No entiendo por qué no tienen incentivos para hacerlo estable y que funcione bien.
Después de sufrir sparse bundles dañados que obligan a empezar un backup nuevo, o fallas de la función, ahora siento que ya no vale mucho la pena configurar Time Machine.
Es un contraste total con los backups de iOS/iPadOS, que siempre me funcionaron bien.
Apple quiere que la gente haga backup de todo en iCloud para aumentar los ingresos por servicios.
Llevo años usando Time Machine sobre recursos compartidos Samba en varias Mac, y solo he visto mejoras.
Antes, los sparse bundles de Time Machine se dañaban con frecuencia y tenía que crearlos de nuevo, o restaurar un snapshot anterior de ZFS para continuar.
Creo que en ese entonces era AFP, no SMB.
Últimamente no he tenido ese problema en ningún equipo, aunque sí tengo activadas en
smb.confciertas flags recomendadas para backups de Time Machine.En cambio, ZFS tiene slop space para evitar que el sistema de archivos se detenga cuando se queda sin espacio en medio de una operación grande.
Por defecto reserva el 3.2% del espacio del volumen, hasta un máximo de 128 GB.
Así que, si cambias el ajuste del kernel de Linux
spa_slop_shiftpara reducir el slop space, puedes recuperar hasta 128 GB de espacio extra para lograr completar una operación de borrado de archivos: https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#spa-slop-shiftPor este motivo, reservar cierto porcentaje del espacio en disco era una función común en sistemas de archivos “de verdad” desde décadas antes de que existieran ZFS o Linux.
Es parecido a cómo la mayoría de los programas shareware de terminal para MS-DOS de los años 80 manejaban muy bien la descarga de archivos en conexiones de ancho de banda limitado, mientras que hoy MS Windows hace pésimamente esa tarea que debería ser trivial.
Para más detalles, consulta
man tune2fs.Lo mismo aplica a la mayoría de los demás sistemas de archivos modernos, y también a muchos no tan modernos.
Si no recuerdo mal, UFS en SunOS en los años 80 también lo hacía: https://en.wikipedia.org/wiki/SunOS
A la gente le cuesta entender la idea de que borrar algo puede requerir realmente más espacio, ya sea temporal o permanentemente.
Otros comentarios ya explicaron en detalle por qué los sistemas de archivos modernos, con snapshots, journaling y cosas similares, necesitan asignar espacio libre para poder borrar.
En otros ámbitos pasa algo parecido: durante la primera década de Wikipedia, había que explicar a menudo que intentar ahorrar espacio en el servidor borrando páginas en realidad tenía el efecto contrario.
Al menos desde alrededor de 2004, una eliminación agregaba un registro a la base de datos interna.
En el formato de archivo ZOO de Rahul Dhesi, borrar una entrada solo marcaba una flag en el registro de encabezado, y también existía el versionado de archivos al estilo VMS, donde agregar una versión nueva no sobrescribía la anterior.
En la época de MS/DR/PC-DOS y FAT, si había instalada una utilidad de recuperación de borrados, borrar un archivo podía requerir más espacio porque guardaba una nueva entrada con información de recuperación en una base de datos.
Algunas utilidades antiguas de compresión de disco comprimían incluso los metadatos, así que también podían darse casos raros en los que un cambio de metadatos alterara la tasa de compresión y aumentara realmente el tamaño visible del volumen.
La idea de borrar para liberar espacio está muy extendida, pero en sentido estricto no siempre es cierta.
En octubre de 2018 me pasó el mismo problema y lo dejé en la siguiente pregunta de Stack Overflow.
Por suerte tenía una partición APFS adicional que podía eliminar, así que pude liberar espacio en disco.
Me tomó bastante tiempo descubrirlo y, mientras tanto, estaba en pleno pánico.
https://apple.stackexchange.com/questions/338721/disk-full-terminal-in-recovery-mode-won-t-delete-files-boot-kernel-panics
Justo después de actualizar a macOS Mojave, estaba creando un
.dmg, llené el disco y el sistema se congeló.Al reiniciar, tuve un kernel panic; arranqué en modo recuperación, monté el disco y ejecuté
rm /path/to/large/fileen la terminal, pero aparecióNo space left on device.Era, en esencia, el mismo problema que en un hilo de Unix de 2008: https://www.unix.com/linux/69889-unable-remove-file-using-rm-disk-space-full.html
echo x > /path/to/large/filetampoco sirvió, y necesitaba alguna sugerencia que no fuera “borra el disco y restaura desde un backup”.Es parecido a cómo los sistemas de archivos Unix antiguos reservaban 5% para root.
Si se elimina la partición de memoria virtual, suponiendo que sea lo bastante grande, puede devolver suficiente espacio como para permitir borrar archivos.
Porque los contenedores solo se asignan cuando realmente se usan.
Impresionante.
Nunca me ha tocado una situación en la que incluso
rmfalle, pero sí he sufrido lo desagradable que es usar y administrar Macs modernos con almacenamiento interno de 256 GB o menos.Por eso suelo crear un archivo marcador de posición de unos 16 GB.
Si de todos modos el espacio se llena y bloquea actualizaciones u otras tareas, basta con borrar ese archivo, sin tener que hacer una limpieza quirúrgica con
ncdu.Por ejemplo, comprar un disco nuevo cuatro veces más grande que el anterior por el costo de una hora de trabajo de una persona o de un equipo.
Me pasó algo parecido también en un iPhone.
El disco estaba tan lleno que, aunque borrara algo, en realidad parecía no pasar nada.
Reinicié y ya no podía iniciar sesión; volví a reiniciar y cayó en un boot loop.
Tras reiniciar una vez más, arrancó en un estado inconsistente: los íconos de apps seguían en la pantalla de inicio, pero las apps reales habían desaparecido, así que los íconos estaban vacíos y no abrían.
Me preocupaba la integridad de los datos, así que al final restauré desde un backup.
Estoy seguro de que esto fue consecuencia de que APFS usa copy-on-write y soporta snapshots.
Si los cambios no se persisten de inmediato y las versiones anteriores de los archivos quedan en snapshots, la situación se complica cuando ni siquiera hay espacio para los metadatos de los snapshots.
Tal vez podría saltarse los snapshots cuando falta espacio en disco, pero aun así queda el problema de los metadatos CoW.
Incluso en 2024, con todas las funciones inteligentes de administración de volúmenes de APFS, sorprende que con solo llenar el almacenamiento de usuario puedas dejar un dispositivo “sellado” como un iPhone en un estado que requiere recuperación DFU.
En cambio, cuando por accidente llené el espacio de una laptop de trabajo con Windows 11 que usa un único volumen de datos/arranque, todavía pude iniciar y limpiar el problema.
Hace poco me pasó una situación parecida en la partición del sistema de una instalación de Linux.
Para empezar, la partición era demasiado pequeña, y a medida que se acumulaban actualizaciones ya casi no quedaba espacio ni para empezar a borrar algo.
Me tomó unos 30 minutos encontrar algún subdirectorio del que pudiera borrar aunque fuera un poquito.
Se sentía como estar atrapado en una habitación tan llena de cosas que no podías abrir una puerta que abre hacia adentro.
A partir de ese pequeño punto inicial pude ir borrando espacios cada vez más grandes y, después de limpiar por fin, amplié el tamaño de la partición para que no volviera a pasar.
Para usuarios avanzados, la lección debería ser dejar siempre algo de espacio libre detrás de la partición.