ZimaOS instala las apps en la unidad del sistema y olvida los discos de datos
Un usuario documenta cómo el sistema ignora los volúmenes adicionales y que sus cambios manuales se pierden con cada actualización.
¿Te suena esto? Tienes un mini PC con ZimaOS, dos discos: uno NVMe de 512 GB para el sistema y un SSD SATA de 500 GB para datos. En la interfaz web ves ambos, con su capacidad y estado. Pero cuando instalas Immich desde la tienda de aplicaciones, los datos no van al SSD: van a parar a la partición de datos del sistema, en el NVMe. El SSD se queda vacío, ignorado, sin que nadie te pregunte dónde quieres guardar la biblioteca de fotos.
Un usuario de Reddit ha abierto una discusión al respecto tras pasarse una noche peleando con el asunto. En su post explica que el problema es general: ZimaOS (la capa de CasaOS) instala todas las aplicaciones de su tienda en la unidad que contiene el sistema operativo, por mucho que haya otras montadas y visibles. No hay selector de volumen en el momento de instalar, ni tampoco opción para cambiarlo después desde la interfaz.
El usuario intentó resolverlo por su cuenta. Primero identificó los puntos de montaje con lsblk: el SSD SATA estaba montado como btrfs en /var/lib/casaos_data/.media/SSD-870, mientras que los datos de la aplicación vivía en ext4 bajo /DATA. Después localizó el archivo Compose generado por la tienda en /DATA/.icewhale/appstore, lo modificó con un sed para redirigir a un directorio en el SSD el volumen correspondiente a la biblioteca de Immich. Dejó la base de datos y la caché del modelo ML en el NVMe porque son datos pequeños pero con alta demanda de I/O aleatorio, y la unidad del sistema tiene mejor rendimiento.
El truco funcionó: docker compose up -d y un docker inspect confirmaron que los originales ya escribían donde debían. Pero hay un inconveniente: cada vez que se actualiza Immich desde la tienda, ZimaOS regenera el Compose a partir de la plantilla oficial y el cambio se esfuma. La biblioteca vuelve a apuntar al sistema. El usuario tiene que repetir el sed tras cada actualización, como un ritual.
Además, el sistema es tan minimalista que ni siquiera tiene comando su, y hay que habilitar SSH manualmente desde los ajustes de desarrollador. No es un obstáculo insalvable, pero suma señales de que ZimaOS está pensado para un usuario que no quiera mirar debajo del capó.
El autor pregunta si es una expectativa equivocada suya como veterano del homelab o si el diseño de ZimaOS/CasaOS no contempla el uso consciente de varios discos. Yo me inclino por lo segundo: no es un fallo puntual de Immich, sino una carencia del sistema. Mientras IceWhale no incluya un selector de volúmenes por aplicación, habrá que apañárselas con ediciones manuales del Compose o plantearse usar Docker directamente, fuera de la tienda. Y si alguien conoce un método nativo para evitar que las actualizaciones pisen los cambios, que lo cuente.
