Solución de la comunidad

Usa discos duros USB externos como almacenamiento de ZimaOS: correcciones de rutas de Immich y compatibilidad USB actual

A March 2026 HP T640 home-NAS thread using three USB HDDs for Immich, backup, and Plex. The Immich container failed because a photo folder was mapped onto /etc/localtime. The community also warned about USB mount timing, but current ZimaOS now officially treats USB drives as normal storage and can add them to arrays.

El usuario de origen de marzo de 2026 estaba construyendo su primer NAS a partir de un cliente ligero HP T640 con un disco de sistema NVMe de 128 GB y tres discos duros conectados por USB. Su plan era sensato: guardar las fotos en un disco externo, hacer copias de seguridad en un segundo disco y almacenar los archivos multimedia de Plex en una unidad independiente de 4 TB. El problema principal no fue que el almacenamiento USB fuera imposible. Immich se detuvo porque las asignaciones de volúmenes de la aplicación se editaron incorrectamente.

La parte del hilo relacionada con las capacidades de almacenamiento también necesita un límite temporal actualizado. En marzo de 2026, el usuario y quien respondió consideraban que las unidades USB eran más limitadas que el almacenamiento interno. La documentación actual de ZimaOS indica explícitamente que las unidades USB siguen la misma lógica de los discos duros y SSD internos y pueden utilizarse para almacenamiento, añadirse a una matriz o emplearse para ampliar el espacio existente.

El NAS de origen dependía completamente del almacenamiento USB

La configuración utilizaba:

  • cliente ligero HP T640 con AMD R1505G, 8 GB de RAM y NVMe de 128 GB;
  • dos discos duros Seagate de 2,5 pulgadas en carcasas USB independientes;
  • un disco duro externo WD de 4 TB para los archivos multimedia de Plex.

Como el cliente ligero no tenía bahías internas para unidades de fácil acceso, el usuario necesitaba que el almacenamiento USB funcionara como almacenamiento NAS principal en lugar de como medio extraíble temporal.

Panel de ZimaOS en un cliente ligero HP que muestra discos externos recién detectados y aplicaciones instaladas, como Plex e Immich
ZimaOS detectó los discos externos, por lo que los problemas principales eran la configuración del almacenamiento y la asignación de volúmenes de las aplicaciones, no la detección básica de USB.

Las unidades aparecían como almacenamiento USB

Configuración de almacenamiento de ZimaOS que muestra dos discos USB llamados Photos y Photos_backup
La instalación de origen reconoció ambos discos de fotos en Ajustes > Almacenamiento.

El usuario creía que las unidades externas no podían tratarse como almacenamiento interno ni usarse para RAID. Eso reflejaba el comportamiento y las expectativas de su configuración de marzo de 2026, no el modelo de almacenamiento actual de ZimaOS.

La versión actual de ZimaOS trata las unidades USB como almacenamiento normal

La documentación actual de IceWhale indica que las unidades USB siguen la misma lógica que los discos duros y SSD internos: pueden usarse como almacenamiento independiente, añadirse a una matriz o utilizarse para ampliar el espacio existente.

Usa el flujo de almacenamiento actual de ZimaOS para las unidades USB en lugar de construir un sistema nuevo basándote en la suposición anterior de que RAID por USB no es compatible categóricamente.

El fallo de Immich fue un error de asignación entre archivo y directorio

El usuario de origen cambió la configuración de volúmenes de Immich y Docker devolvió un error indicando que no podía montar:

/media/Photos/Immich
→ /etc/localtime

/etc/localtime dentro del contenedor es un archivo, no un directorio de biblioteca fotográfica. Por eso Docker rechazó el intento de montar una carpeta sobre ese archivo.

Configuración de volúmenes de Immich que muestra el directorio de carga normal y una asignación independiente del archivo /etc/localtime
La configuración correcta mantiene separado el directorio de carga de fotos del /etc/localtime asignación de archivos.

Mantén el almacenamiento de fotos y /etc/localtime como montajes independientes

El respondedor de la comunidad separó correctamente las dos funciones:

  • carpeta de fotos del host → directorio de carga o datos de Immich;
  • host /etc/localtime archivo → contenedor /etc/localtime archivo.

Las reglas actuales de montajes bind de Docker siguen exigiendo que los tipos de origen y destino coincidan. Un directorio no puede montarse sobre un archivo como si fueran intercambiables.

La solución alternativa del montaje bind de /DATA era una sugerencia histórica de la comunidad

El respondedor también sugirió crear un directorio estable debajo de /DATA y montar mediante bind la ruta USB allí porque los discos externos podrían no estar listos cuando las aplicaciones se iniciaran después de reiniciar.

Esa era una recomendación de la comunidad para la versión de origen. El ZimaOS actual ofrece una compatibilidad más sólida con el almacenamiento USB administrado, por lo que una instalación nueva debería usar primero la interfaz de Almacenamiento y el selector de volúmenes administrados de la aplicación, en lugar de crear un montaje bind personalizado durante el arranque.

Apunta Immich al almacenamiento administrado, no a una ruta de dispositivo sin procesar

El ZimaOS actual recomienda colocar los datos de las aplicaciones y las bibliotecas multimedia grandes en el espacio de almacenamiento destinado a contenerlos, en lugar de llenar la unidad del sistema. Usa la ruta del host seleccionada por ZimaOS y conserva la ruta del contenedor que Immich espera.

Para las asignaciones actuales de aplicaciones, el modelo de rutas de almacenamiento de aplicaciones de ZimaOS explica cómo encajan las rutas del host y del contenedor.

RAID y las copias de seguridad siguen resolviendo problemas distintos

Aunque el ZimaOS actual puede usar unidades USB en matrices, RAID 1 no sustituye una segunda copia de seguridad independiente. Dos discos USB en una misma matriz protegen frente a un fallo de uno de los discos miembros, pero no frente a eliminaciones accidentales, malware, problemas con la carcasa o el controlador, ni la pérdida de todo el NAS.

La idea del usuario original de conservar una copia adicional sigue siendo útil, aunque el conjunto de funciones de almacenamiento haya cambiado.

Los medios de Plex son más sencillos que el estado de la aplicación Immich

El usuario consideró prescindible la unidad Plex de 4 TB porque el contenido de video podía reemplazarse. Es una distinción de riesgo razonable: los archivos multimedia, las fotos de Immich, el estado de la base de datos de Immich y la configuración de la aplicación no necesariamente requieren la misma política de redundancia o copias de seguridad.

Preguntas frecuentes sobre el almacenamiento USB externo

¿Puede el ZimaOS actual usar unidades USB como almacenamiento administrado?

Sí. La documentación actual de Almacenamiento admite explícitamente las unidades USB como almacenamiento y miembros de matrices.

¿Por qué Immich dejó de funcionar después de cambiar el directorio?

La carpeta de fotos se asignó accidentalmente al /etc/localtime ruta del archivo.

¿Los usuarios actuales deberían crear montajes bind manuales de /DATA para cada unidad USB?

No. Esa era una solución alternativa histórica de la comunidad. Comienza con los controles actuales de Almacenamiento administrado y volúmenes de aplicaciones.