En resumen: no reformatees NTFS solo porque Windows muestre un recurso compartido de ZimaOS vacío o de solo lectura
El caso de 2024 combinaba tres síntomas: Windows encontraba el equipo ZimaOS, pero no mostraba carpetas compartidas; las credenciales no se solicitaban de forma coherente; y las operaciones de copia fallaban o se ralentizaban. Se sospechó de NTFS, pero IceWhale confirmó explícitamente que los discos NTFS podían funcionar mediante SMB. Por lo tanto, reformatear debe ser el último paso, no el primero.
El comportamiento actual de SMB en ZimaOS es mucho más claro: los recursos compartidos se autentican, los permisos se asignan como Lectura o Lectura y escritura, y las credenciales antiguas de Windows pueden hacer que un recurso válido parezca vacío o inaccesible.
Paso 1: conéctate al recurso compartido exacto con la cuenta prevista
No dependas únicamente del icono del dispositivo en Red de Windows. Introduce directamente el recurso compartido:
\ZIMAOS-IP\SHARE-NAMESi Windows reutilizó silenciosamente una cuenta antigua, elimínala primero:
net use \ZIMAOS-IP\ /delete /y
cmdkey /delete:ZIMAOS-IPLa solución de problemas de SMB de ZimaOS actual señala explícitamente que la autenticación incorrecta y las credenciales almacenadas pueden causar recursos compartidos en blanco y largos retrasos de conexión.
Paso 2: verifica el permiso de Lectura y escritura en ZimaOS
Un usuario que puede abrir un recurso compartido aún puede no tener permiso de escritura. Abre la configuración del recurso compartido de Samba, selecciona el miembro correspondiente y confirma Lectura y escritura. El ZimaOS actual separa el acceso de Miembros y Huéspedes, y permite al administrador elegir Lectura o Lectura y escritura para cada recurso compartido.
Los miembros de Samba de ZimaOS constituyen el modelo de permisos actual. La autenticación SMB de ZimaOS proporciona el flujo de conexión del cliente.
Paso 3: separa la compatibilidad del sistema de archivos de la autenticación SMB
NTFS, exFAT y los sistemas de archivos nativos de Linux no exponen la propiedad ni los permisos exactamente de la misma forma, pero un disco NTFS no queda automáticamente inutilizado mediante Samba. Primero comprueba si ZimaOS puede leer y escribir el disco localmente, si el miembro de Samba tiene permiso de escritura y si Windows está utilizando la cuenta esperada.
Si el disco contiene datos existentes, no lo formatees nunca solo para probar una hipótesis sobre SMB. Usa en su lugar otro disco o carpeta de prueba vacíos.
Paso 4: diagnostica las transferencias lentas por separado
Que una copia pase de una velocidad de ráfaga alta a una velocidad sostenida mucho menor puede deberse a la caché del disco, archivos pequeños, almacenamiento USB, discos SMR, la negociación de red o el procesamiento del servidor. Mide las distintas capas por separado:
# Prueba de escritura del disco local de ZimaOS en una ruta prescindible
dd if=/dev/zero of=/media/STORAGE/test.img bs=1M count=2048 status=progress conv=fdatasync
# rendimiento de red, cuando iperf3 esté disponible
iperf3 -s
iperf3 -c SERVER-IPLas pruebas de red con iperf separan la velocidad de red del comportamiento del disco y de Samba. El protocolo SMB de Windows proporciona el contexto del protocolo en Windows.
Paso 5: prueba una carpeta de almacenamiento de ZimaOS que sepas que funciona
Crea una carpeta de prueba pequeña en un espacio de almacenamiento administrado por ZimaOS, compártela con un miembro con permiso de Lectura y escritura, borra las credenciales de Windows y copia un único archivo de 1–2 GB. Si funciona, el servicio básico de Samba y el modelo de cuentas están funcionando correctamente. Vuelve a incorporar el disco externo NTFS/exFAT después de la prueba de control.
No uses el acceso de Huésped para ocultar un problema de credenciales
El acceso de Huésped puede hacer que las pruebas parezcan más sencillas, pero elimina la evidencia necesaria para verificar qué cuenta posee la conexión. Para un recurso compartido permanente doméstico o de equipo, las credenciales explícitas de los miembros son más fáciles de auditar y permiten asignar distintos permisos de Lectura y escritura.
El artículo sobre compartición de archivos NAS ayuda a elegir entre SMB directo en la LAN, ZimaClient y otras vías de acceso a archivos.
Cuando el recurso compartido sigue siendo de solo lectura
Comprueba la ruta real del host, el estado del montaje y la posibilidad de escritura del sistema de archivos local. Si el propio ZimaOS no puede crear un archivo en el disco montado, Samba no puede conceder capacidades que el sistema de archivos o el montaje no proporcionan. Si las escrituras locales funcionan, pero las escrituras mediante SMB fallan, vuelve a revisar los permisos del recurso compartido y las credenciales de sesión de Windows en lugar de formatear el disco.
Preguntas frecuentes
¿NTFS causa problemas con SMB en ZimaOS?
NTFS puede tener una semántica de permisos diferente en Linux, pero no es inherentemente incompatible con SMB en ZimaOS. Primero diagnostica los permisos de la cuenta y la posibilidad de escritura local del disco.
¿Por qué Windows muestra una carpeta de ZimaOS vacía?
Una credencial almacenada o anónima puede conectarse sin los permisos que esperabas. Borra las sesiones SMB existentes de Windows y vuelve a conectarte con el miembro de ZimaOS previsto.
¿Por qué puedo leer archivos, pero no copiar otros nuevos?
El recurso compartido puede estar configurado como Lectura en lugar de Lectura y escritura, o el sistema de archivos montado subyacente puede estar en modo de solo lectura.
¿Debería activar el acceso de Huésped?
Usa Huésped únicamente cuando se requiera intencionadamente el acceso anónimo. No es una buena solución permanente para unas credenciales defectuosas.
¿Cómo sé si la lentitud de SMB se debe a la red o al disco?
Mide por separado el rendimiento bruto de la LAN y la velocidad de escritura del disco local; después compara esos resultados con la transferencia mediante SMB.
