Si Linux detecta un SSD NVMe, pero este aparece en la bahía incorrecta de ZimaCube —o no se muestra correctamente en la interfaz de almacenamiento—, el problema puede estar en los metadatos de asignación de bahías de ZimaOS y no en el propio SSD. Comprueba primero la detección PCIe y, después, utiliza el restablecimiento de local-storage.conf únicamente en hardware para el que IceWhale haya documentado o recomendado esa solución alternativa.
El hilo original establece un límite importante entre modelos: eliminar la NVME=... línea y reiniciando zimaos-local-storage.service corrigió el caso original de ZimaCube, pero posteriormente IceWhale indicó que ese método se aplicaba a ZimaCube y no funcionaba de la misma manera en un Intel NUC genérico.
Paso 1: Confirma que el NVMe existe en la capa PCIe
Ejecuta:
lspci | grep -i -E 'non-volatile|nvme'
lsblk -o NAME,SIZE,MODEL,SERIALSi el SSD no aparece en ninguna de las dos vistas de hardware, el problema no es simplemente el gráfico de bahías de ZimaOS.
La guía de resolución de problemas de almacenamiento es útil cuando el NVMe falta en la capa de hardware, en lugar de estar simplemente representado de forma incorrecta en la interfaz web.
Paso 2: Comprueba la asignación de bahías del ZimaCube
En el ZimaCube afectado, IceWhale solicitó:
sudo -i
cat /etc/casaos/local-storage.confLa configuración contenía una NVME=... asignación que ya no coincidía con la ubicación del SSD.
Paso 3: Usa el restablecimiento solo en el modelo previsto
IceWhale indicó al usuario de ZimaCube que eliminara la NVME=... línea y luego ejecuta:
systemctl restart zimaos-local-storage.serviceEl usuario original confirmó que esto corrigió la interfaz.
Por qué mover el SSD puede recrear el problema
Más tarde, un usuario pasó el SSD de una bahía a otra y la asignación incorrecta volvió a aparecer. Esto tiene sentido si el mapa de bahías almacenado en caché o personalizado ya no coincide con la nueva ranura física.
No apliques esto a hardware genérico sin más
Un usuario de un Intel NUC intentó la misma edición y la línea de NVMe volvió a aparecer sin corregir la interfaz. IceWhale indicó explícitamente que el método se aplicaba a ZimaCube y que el comportamiento más amplio de los compartimentos de unidades personalizados para otros modelos aún estaba en desarrollo.
Primero, comprueba la interfaz de almacenamiento actual
La guía actual de configuración de almacenamiento de ZimaOS documenta la detección de discos y la configuración del almacenamiento actuales. Si el SSD aparece como almacenamiento normal, pero el gráfico de la bahía es incorrecto, considéralo un problema de presentación o asignación.
Usa los privilegios de root con cuidado
El hilo original también aclaró que editar /etc/casaos/local-storage.conf requiere privilegios de root. No fuerces la escritura del archivo desde una sesión de usuario normal.
Separa la detección física de la presentación de las bahías
La página de almacenamiento de ZimaCube intenta asignar los controladores NVMe detectados a etiquetas de ranuras físicas. Esa capa de presentación adicional explica por qué un disco puede ser perfectamente visible para Linux y, aun así, aparecer bajo la letra equivocada o con un gráfico de bahía extraño.
Antes de editar la configuración, registra el modelo del SSD, la dirección PCI y la ranura física. Esto proporciona un mapa de antes y después y reduce la posibilidad de “solucionar” el dispositivo equivocado.
Haz una copia de seguridad de local-storage.conf antes de editarlo
Si el soporte de IceWhale te indica que modifiques el archivo, haz primero una copia:
sudo -i
cp /etc/casaos/local-storage.conf /etc/casaos/local-storage.conf.bakDespués, realiza únicamente el cambio solicitado. Evita reescribir configuraciones de almacenamiento no relacionadas, porque el archivo contiene más información que la asignación de NVMe.
Reinicia primero el servicio de almacenamiento, no todo el servidor
La solución verificada para ZimaCube reinició zimaos-local-storage.service después de borrar la asignación obsoleta. Esta es una prueba más específica que reiniciar todo el NAS y facilita determinar si el servicio de almacenamiento local reconstruyó correctamente el mapa de bahías.
Si la asignación sigue reapareciendo
Cuando la misma asignación obsoleta reaparece después de cada reinicio, deja de editar repetidamente el archivo. Captura la configuración generada, lspci, lsblk, la ranura física y la versión actual de ZimaOS para el soporte. La regeneración persistente significa que otro componente está escribiendo la asignación.
La {ilink("https://shop.zimaspace.com/pages/zimaos-installation-troubleshooting-guide","guía de solución de problemas de almacenamiento","Recopila la detección del hardware y los metadatos de almacenamiento antes de realizar repetidas modificaciones a nivel del sistema")} proporciona un marco de escalamiento más seguro.
Preguntas frecuentes
¿Eliminar la línea NVME borra el SSD?
La solución alternativa original modificaba la configuración de asignación de bahías, no el contenido del disco. Aun así, haz una copia de seguridad de los datos importantes antes de realizar cambios en el almacenamiento a nivel del sistema.
¿Por qué el SSD aparece en lspci, pero no correctamente en la interfaz?
Eso apunta a los metadatos de almacenamiento de ZimaOS o a la asignación de bahías, no a la detección básica de PCIe.
¿Puedo usar esta solución en un Intel NUC?
No como regla general. IceWhale indicó específicamente que la solución alternativa se aplicaba a ZimaCube.
¿Qué ocurre si el SSD no aparece en lspci?
Luego investiga primero la ranura de hardware, el SSD, la configuración de BIOS/PCIe y la conexión física.
