Verifica que los recursos compartidos fantasma provienen del servidor
El propietario de ZimaCube aún podía ver y montar recursos compartidos SMB vacíos de dos intentos fallidos de configuración de RAID5. Los recursos compartidos actuales en ZimaOS 1.2.2 se podían añadir y eliminar con normalidad, pero los nombres antiguos seguían apareciendo en el selector de recursos compartidos de red.
Un Mac que nunca se había conectado a ZimaCube mostraba los mismos nombres obsoletos. Esa comprobación descartó una caché limitada a un solo cliente y situó el estado obsoleto en el servidor.
Repite esta comprobación de bajo riesgo antes de cambiar el servidor: compara la lista de un cliente nuevo o de un perfil limpio con los recursos compartidos activos que aparecen en Archivos de ZimaOS. Registra qué entradas son reales y cuáles se montan vacías.
No reconstruyas el RAID funcional para eliminar nombres de recursos compartidos
El equipo declaró que su principio de reparación era evitar obligar a los usuarios a reconstruir o volver a cargar los datos del RAID, salvo que fuera inevitable. Más tarde confirmó que el problema de los recursos compartidos no afectaría a los datos existentes del RAID.
Esto separa la integridad del almacenamiento de la limpieza de la lista de recursos compartidos. Verifica primero el conjunto actual y los recursos compartidos reales. Si el RAID está sano y los datos siguen siendo accesibles, los nombres fantasma no indican que haya que recrear el conjunto.
Si el conjunto está degradado o ha desaparecido, detente y trátalo como un incidente de recuperación independiente. No combines una reparación del almacenamiento con la limpieza de SMB, porque perderías la capacidad de determinar qué cambio afectó a cada problema.
El equipo confirmó un error en la gestión de recursos compartidos
Un miembro del equipo de ZimaOS confirmó que las operaciones de archivos y almacenamiento no estaban asociadas entonces con la limpieza de recursos compartidos. Otro usuario informó de un síntoma relacionado: cambiar el nombre o eliminar una carpeta compartida dejaba activo su antiguo nombre SMB.
El problema original comenzó después de que ZimaOS 1.2 no conservara la configuración del RAID tras los ciclos de encendido. La actualización a 1.2.1 y 1.2.2 detuvo el fallo de persistencia del RAID, pero los registros obsoletos de recursos compartidos permanecieron.
ZimaOS 1.2.3 no los eliminó. El equipo dijo que la corrección estaba prevista para 1.2.4 y ofreció asistencia remota antes de entonces, pero el tema no contiene ninguna publicación posterior que confirme que 1.2.4 eliminara las entradas del autor. Conserva ese límite de versiones.
Evita editar manualmente los archivos Samba generados
El autor encontró definiciones obsoletas en /etc/samba/smb.casa.conf. Editar, eliminar o reemplazar ese archivo no persistía después de reiniciar, y la lista de red a veces contenía más nombres que el propio archivo.
Ese comportamiento indica que otro componente regeneraba o proporcionaba el estado de los recursos compartidos. Las ediciones manuales repetidas pueden provocar divergencias con la gestión de ZimaOS sin producir una reparación duradera.
Revierte cualquier cambio experimental, mantén intacto el RAID activo y utiliza la interfaz compatible, la ruta de actualización o el proceso de asistencia remota. La recuperación debe validarse desde un cliente nuevo después de reiniciar, no solo inspeccionando un archivo de configuración.
Escala el problema con un inventario reproducible de recursos compartidos
Si una actualización compatible no elimina las entradas fantasma, captura la versión de ZimaOS, la lista de recursos compartidos de Archivos, el selector de recursos compartidos del cliente y los nombres que se montan vacíos. Indica que la misma lista aparece en un cliente nuevo.
Solicita la corrección del estado de los recursos compartidos sin autorizar una reconstrucción del RAID, salvo que las pruebas de almacenamiento la requieran de forma independiente. El equipo ofreció asistencia remota específicamente para eliminar los recursos compartidos fantasma antes de su actualización prevista.
Después de la corrección, reinicia una vez, vuelve a conectarte desde un cliente existente y desde uno nuevo, y confirma que solo aparecen los recursos compartidos activos y que abren las rutas esperadas. Esta prueba completa demuestra la recuperación.
Preguntas frecuentes
¿Los recursos compartidos SMB fantasma son solo un problema de caché de macOS?
No en este caso. Un Mac sin ninguna conexión previa a ZimaCube vio las mismas entradas.
¿ZimaOS 1.2.3 eliminó los recursos compartidos antiguos?
No. El autor informó explícitamente de que la versión 1.2.3 no los solucionó.
¿El tema confirmó que ZimaOS 1.2.4 corrigió el error?
El equipo tenía prevista la corrección para la versión 1.2.4, pero el hilo no incluye una validación final por parte del usuario.
