No se puede acceder al servidor samba Ubuntu a través de la ruta UNC del nombre de host (la IP funciona) en el explorador de Windows

No se puede acceder al servidor samba Ubuntu a través de la ruta UNC del nombre de host (la IP funciona) en el explorador de Windows

Configuración

Tenemos un servidor AD ejecutándose en Windows Server 2012 ( ad01.<domainroot>). Hay un servidor de archivos Samba ejecutándose en Ubuntu 20.04 ( fs02.<domainroot>). El servidor de archivos está unido al dominio mediante winbind.

En esta publicación usaré<raíz de dominio>ser el marcador de posición equivalente deAD.EJEMPLO.ORGy<grupo de trabajo>para el grupo de trabajo.

Problema

No podemos acceder al servidor/compartidos samba a través de su nombre de host, recibimos un error de red que dice que es inalcanzable:

ingrese la descripción de la imagen aquí.

El problema es el mismo si se utiliza el FQDN.

Si navego hasta él a través de su IP ( \\<fs02 IP>), funciona sin problemas, por lo que los recursos compartidos parecen ser correctos. (smb.conf agregado a continuación)

lo que he probado

Mi idea inicial fue verificar el DNS, pero nslookup fs02me da la respuesta correcta. También puedo hacer ping sin problemas.

También intenté jugar con smb.conf, esta es la configuración que estoy usando actualmente:

[global]
security = domain

workgroup=<workgroup>
realm=<domainroot>
netbios name = fs02

# === logging config ===
log file = /var/log/samba/%m.log
log level = 1

# === Backend setup ===

idmap config * : backend = tdb
idmap config * : range = 2000-9999
idmap config <workgroup> : backend = rid
idmap config <workgroup> : range = 10000-30000

winbind use default domain = yes
winbind nested groups = yes
winbind refresh tickets = yes

inherit owner = yes
vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes

unix extensions = yes

# === Share definitions ===
# ... pruned ...

Respuesta1

El problema en mi caso se debió a una configuración NTP defectuosa que provocaba una diferencia de tiempo entre varios servidores. Reiniciar el reloj manualmente verificó el problema y arreglar la configuración NTP evitó que la deriva volviera a ser un problema.

información relacionada