Un nuevo usuario de ZimaOS solo podía copiar archivos a un recurso compartido de Samba desde el Explorador de archivos de Windows cuando se añadía la cuenta de invitado sin protección. Una vez eliminado el acceso de invitado, Windows declaró que los recursos compartidos no estaban disponibles y no mostró un nuevo aviso para introducir el nombre de usuario y la contraseña.
El caso se resolvió sin dejar activado el acceso de invitado. El miembro del equipo de Zima, Giorgio, pidió al usuario que eliminara todas las credenciales guardadas por Windows y volviera a ejecutar el script de conexión de Samba de la comunidad. El autor confirmó que esto eliminó el conflicto y restableció el acceso.
Configuración original de ZimaOS y Windows
El usuario había instalado ZimaOS 1.4.1 en un sistema ASUS Prime N100I-D D4. Un SSD M.2 Crucial de 500 GB contenía el sistema operativo, mientras que un único disco duro Seagate de 1 TB se exponía como unidad compartida a través de la interfaz web de ZimaOS.
Con el usuario invitado activado, pegar la URL del recurso compartido desde Administrar recurso compartido en el Explorador de archivos de Windows funcionaba. La parte confusa era que, en ese estado, también parecía posible acceder a otro recurso compartido protegido por contraseña, aunque el invitado no aparecía configurado para él.
Por qué los primeros intentos con las credenciales no ayudaron
El autor sospechaba que se trataba de un problema de credenciales y añadió manualmente una entrada en el Administrador de credenciales de Windows. También siguió la página de ayuda de SMB de ZimaOS y el tutorial de conexión mediante la línea de comandos de la comunidad. El script solicitaba las credenciales, pero introducir el nombre de usuario y la contraseña esperados de ZimaOS todavía no abría inicialmente el recurso compartido.
Un detalle potencialmente relevante era que el mismo servidor y la misma dirección IP habían ejecutado anteriormente TrueNAS. El hilo no demostró que la instalación anterior causara el conflicto, pero Windows tenía varias credenciales web y de Windows guardadas cuando se diagnosticó el problema.
La solución confirmada: eliminar primero todas las credenciales guardadas
La secuencia indicada por Giorgio consistía en eliminar todas las credenciales guardadas desde el Panel de control de Windows, volver a crear un recurso compartido si era necesario y repetir después el tutorial de conexión de Samba de ZimaOS mediante la línea de comandos. El autor eliminó las credenciales web y las credenciales de Windows, volvió a ejecutar el archivo por lotes del tutorial y confirmó que por fin funcionaba el acceso al recurso compartido protegido.
El resultado es importante porque activar el acceso de invitado solo fue una solución temporal en este caso. El procedimiento que funcionó consistió en hacer que Windows olvidara el estado conflictivo de las credenciales antes de autenticarse de nuevo.
Cómo se veían las pantallas de Zima Client
Otro miembro de la comunidad compartió las pantallas esperadas de Zima Client y Windows 11 correspondientes a una configuración funcional de una unidad asignada. Estas capturas no fueron la solución que resolvió el conflicto de credenciales del autor, pero ayudaron a distinguir el cliente descargable del tutorial independiente de la CLI.
Preguntas frecuentes
¿Este usuario necesitaba mantener activado el acceso de invitado?
No. El acceso de invitado hizo que los recursos compartidos fueran accesibles temporalmente, pero la solución confirmada consistió en eliminar todas las credenciales de Windows guardadas y volver a conectarse mediante la cuenta protegida.
¿Añadir manualmente una credencial resolvió el problema?
No. El autor ya había intentado añadir credenciales manualmente. El intento que funcionó solo se produjo después de eliminar todas las credenciales web y de Windows guardadas y volver a ejecutar el script de conexión.
