«Ruta de red no encontrada» (0x80070035): la solución en 5 minutos

febrero 25, 2026 • febrero 25, 2026 • Lectura: 23 min • Views: 1

¿Te fue útil?

Son las 9:07 a.m. Alguien no puede abrir \\fileserver\finance. El director financiero está en la llamada. Lo pruebas tú mismo y—boom—Windows lanza
“Ruta de red no encontrada” con 0x80070035. No es “acceso denegado”. No es “contraseña incorrecta”. Ni siquiera te da una pista.

Este error es la forma de Windows de decir: “No puedo llegar desde aquí.” Ese “allí” puede ser DNS, enrutamiento, SMB, reglas de firewall o un recurso compartido
que ya no existe porque alguien “ordenó” un clúster de almacenamiento a las 2 a.m. Vamos a arreglarlo en cinco minutos—la mayoría de las veces—y
saber exactamente qué hacer cuando no es un problema de cinco minutos.

Guía de diagnóstico rápido (comprobar primero, segundo, tercero)

Cuando ves 0x80070035, no empieces reiniciando cosas. Los reinicios son la forma de borrar evidencia y perder tiempo en reuniones.
Empieza demostrando qué capa está fallando.

1) ¿Es resolución de nombres o transporte?

Prueba la IP: \\10.20.30.40\share. Si la IP funciona pero el nombre falla, es DNS/NetBIOS/orden de búsqueda de hosts.
Comprueba el TCP 445: si el 445 está bloqueado, SMB está muerto al llegar. Arregla firewall/enrutamiento, no los “permisos”.

2) ¿SMB es accesible pero falta el recurso compartido?

Enumera los recursos compartidos remotamente (o al menos accede a \\server en el Explorador). Si el servidor responde pero el recurso no, es un problema de nombre/ruta del recurso.
Revisa el servicio SMB en el servidor: si el servidor no ofrece SMB, Windows reportará “ruta no encontrada” con máxima confianza.

3) ¿Es autenticación disfrazada de “no encontrado”?

Algunos entornos mapean fallos de autenticación, desajustes de SMB signing o bloqueos por políticas en errores genéricos.
Revisa los registros de eventos de Windows y los registros SMB del servidor. Si puedes alcanzar 445 pero las sesiones fallan, es auth/política.

4) Delimita el radio del problema en 60 segundos

¿Un solo usuario? Es configuración local, split tunneling de VPN o caché de credenciales.
¿Un solo subred? Es segmentación de firewall o ACL de enrutamiento.
¿Todos? Es el servidor, el almacenamiento que lo sustenta o una dependencia de infraestructura compartida (DNS, AD, push de políticas de firewall).

Idea parafraseada, atribuida a Gene Kim (autor sobre DevOps/operaciones): Los equipos operativos de alto rendimiento reducen el tiempo medio de recuperación practicando y estandarizando el diagnóstico.
La guía anterior es tu estandarización.

Qué significa realmente 0x80070035 (y qué no significa)

0x80070035 es Windows devolviendo ERROR_BAD_NETPATH. Traducción: el cliente intentó acceder a una ruta UNC
y no pudo establecer una ruta de red válida. Eso puede ocurrir antes de que las credenciales se consideren siquiera.

La trampa es suponer que es “algo de red” en el sentido físico. Podría ser, pero con frecuencia es un asunto de nombre (DNS),
una cuestión de política (reglas de firewall, endurecimiento SMB) o de disponibilidad del servicio (SMB detenido, NAS bloqueado).

Lo que suele ser

Fallo en resolución DNS: el nombre apunta a una IP antigua, VLAN equivocada o registro obsoleto.
TCP 445 bloqueado: “mejora de seguridad” que olvidó que existen servidores de archivos.
Servidor SMB sin escucha: servicio caído, SMB del NAS deshabilitado o puerto no enlazado.
Recurso compartido renombrado/eliminado: la ruta literalmente ya no existe.
Características del cliente desactivadas: cliente SMB deshabilitado, política de descubrimiento de red o pila de estación de trabajo rota.

Lo que normalmente no es

Permisos NTFS (estos suelen dar “Access is denied” o pedir credenciales).
Un “fallo” aleatorio de Windows que se arreglará solo con “inténtalo más tarde”. “Inténtalo más tarde” no es una estrategia.

La solución en 5 minutos: el camino más corto a la verdad

Aquí está el orden de operaciones opinado. Síguelo. Desvíate solo si tienes evidencia.

Minuto 1: Evitar la resolución de nombres

Si \\fileserver\share falla, prueba \\IP\share. Esta es la bifurcación más rápida del camino.
Si la IP funciona, deja de tocar firewalls y empieza a arreglar DNS/resolución de nombres.

Minuto 2: Demuestra que la ruta de red existe (TCP 445)

SMB en Windows moderno es TCP 445. Si ese puerto no conecta, nada más importa.
No puedes negociar SMB con buenas intenciones.

Minuto 3: Comprueba si el servidor ofrece SMB

Si 445 es accesible pero el recurso “no se encuentra”, confirma que el servicio SMB esté en ejecución y que el recurso exista.
Si es un NAS, confirma que no haya cambiado de SMB a “seguridad primero: solo NFS” tras una actualización de firmware.

Minuto 4: Elimina rarezas del cliente local

Vacía la caché DNS, elimina unidades mapeadas obsoletas y verifica que la estación de trabajo esté en la red correcta (el split tunneling de VPN vuelve a aparecer).

Minuto 5: Revisa los registros donde vive la verdad

En Windows: registros Operativos de SMBClient. En servidores: registros SMBServer, registros de seguridad y auditorías del NAS. El código de error en el registro suele ser más honesto que el Explorador.

Broma #1: SMB es como una máquina expendedora—cuando dice “no encontrado”, normalmente el snack está ahí, pero la ranura está atascada.

Tareas prácticas: comandos, salida esperada y la decisión que tomas

A continuación hay tareas reales que puedes ejecutar. Cada una incluye: el comando, salida típica, lo que significa y la decisión que tomas a continuación.
Uso comandos de Windows; la etiqueta del prompt es solo para satisfacer las reglas de formato. Ejecútalas en PowerShell o CMD.

Task 1: Confirmar que el nombre resuelve a la IP correcta

cr0x@server:~$ nslookup fileserver.corp.example
Server:  dns01.corp.example
Address: 10.10.0.10

Name:    fileserver.corp.example
Address: 10.20.30.40

Qué significa: DNS resuelve. Ahora verifica que 10.20.30.40 sea realmente tu servidor de archivos y no una IP reciclada.
Si la IP es incorrecta, has encontrado la causa raíz.

Decisión: Si DNS está mal, corrige el registro A, elimina registros obsoletos o ajusta el sufijo DNS del cliente. No “soluciones temporales” con hosts a menos que te gusten las futuras interrupciones.

Task 2: Comprueba qué piensa Windows que debe resolver el nombre

cr0x@server:~$ ping -4 fileserver
Pinging fileserver [10.20.30.40] with 32 bytes of data:
Reply from 10.20.30.40: bytes=32 time<1ms TTL=127

Qué significa: El cliente puede resolver y alcanzar la IP vía ICMP. Esto no prueba que SMB funcione, pero sugiere que el enrutamiento es correcto.

Decisión: Si ping falla pero DNS resuelve, prueba enrutamiento/VPN y firewall local. Si ping funciona, pasa al puerto 445.

Task 3: Demuestra que TCP 445 es accesible desde el cliente

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection fileserver -Port 445 | Format-List ComputerName,RemoteAddress,TcpTestSucceeded"
ComputerName    : fileserver
RemoteAddress   : 10.20.30.40
TcpTestSucceeded: True

Qué significa: Puedes abrir una conexión TCP a SMB. Los firewalls y el enrutamiento entre el cliente y el servidor probablemente estén bien.

Decisión: Si TcpTestSucceeded: False, detente. Arregla reglas de firewall, ACLs de segmentación, políticas de VPN o el estado de escucha del servidor. No toques permisos de recursos todavía.

Task 4: Valida que estás alcanzando el servidor previsto (reverse lookup + ARP)

cr0x@server:~$ arp -a 10.20.30.40
Interface: 10.20.30.123 --- 0x11
  Internet Address      Physical Address      Type
  10.20.30.40           00-15-5d-4b-12-34     dynamic

Qué significa: Estás hablando con una MAC en tu camino L2. En redes extrañas, las IP incorrectas pueden reasignarse silenciosamente.

Decisión: Si la MAC no es la esperada (o cambia), investiga conflictos de IP, DHCP mal configurado o una VM clonada rogue.

Task 5: Prueba la ruta UNC por IP para evitar DNS por completo

cr0x@server:~$ powershell -NoProfile -Command "dir \\10.20.30.40\finance"
Get-ChildItem : Cannot find path '\\10.20.30.40\finance' because it does not exist.
At line:1 char:1
+ dir \\10.20.30.40\finance
+ ~~~~~~~~~~~~~~~~~~~~~~~~~

Qué significa: La ruta de red hacia el host existe (si 445 es accesible), pero el nombre del recurso puede no existir.
Esto es distinto a no poder alcanzar el servidor en absoluto.

Decisión: Confirma el nombre del recurso (la insensibilidad a mayúsculas no es tu problema; la ortografía sí). Verifica en el servidor/NAS: el recurso existe y está exportado por SMB.

Task 6: Enumera recursos compartidos en un servidor Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare -CimSession fileserver | Select-Object Name,Path,Description"
Name     Path              Description
----     ----              -----------
finance  D:\Shares\Finance  Finance department share
public   D:\Shares\Public   General share

Qué significa: El recurso existe en el servidor, y tienes derechos para consultarlo (o ejecutaste como admin con credenciales apropiadas).

Decisión: Si el recurso no aparece listado, no es un problema del cliente. Arregla la configuración del servidor, el rol del clúster o el montaje del almacenamiento subyacente.

Task 7: Verifica que el servicio SMB está en ejecución (lado servidor Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service -Name LanmanServer | Select-Object Name,Status,StartType"
Name         Status  StartType
----         ------  ---------
LanmanServer Running Automatic

Qué significa: El servidor está ofreciendo SMB. Si está detenido, los clientes Windows a menudo verán “ruta no encontrada” mientras intentan sin éxito.

Decisión: Si Status es Stopped, inícialo e investiga por qué se detuvo (parcheo, fallo de dependencias, endurecimiento de seguridad).

Task 8: Confirma que el servidor escucha en TCP 445

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 445 -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess"
LocalAddress LocalPort OwningProcess
------------ --------- ------------
0.0.0.0      445       4
::           445       4

Qué significa: Algo (típicamente el proceso System) está escuchando en 445 tanto en IPv4 como en IPv6.

Decisión: Si nadie está escuchando, arregla el servicio SMB, el enlace de puertos o la política que deshabilitó SMB.

Task 9: Revisa reglas del Firewall de Windows relevantes a SMB (cliente o servidor)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Select-Object DisplayName,Enabled,Profile | Format-Table -AutoSize"
DisplayName                                      Enabled Profile
-----------                                      ------- -------
File and Printer Sharing (SMB-In)                True    Domain
File and Printer Sharing (SMB-In)                False   Public
File and Printer Sharing (SMB-In)                False   Private

Qué significa: SMB entrante está permitido solo en el perfil Domain. Si el servidor piensa que está en Public, estás bloqueado.

Decisión: Corrige la clasificación del perfil de red o habilita la regla en el perfil correcto. No solo “apagues el firewall” a menos que te guste tener que explicarlo después.

Task 10: Confirma el perfil de red del cliente (Domain vs Public)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Select-Object Name,NetworkCategory,IPv4Connectivity"
Name               NetworkCategory IPv4Connectivity
----               --------------- ----------------
CorpLAN            DomainAuthenticated Internet

Qué significa: El cliente cree que está en una red de dominio. Si dice Public, Windows aplicará valores predeterminados de firewall y comportamiento de descubrimiento más estrictos.

Decisión: Si está en Public inesperadamente, investiga NLA (Network Location Awareness), postura de VPN y conectividad al dominio.

Task 11: Comprueba si las características del cliente SMB están presentes y habilitadas

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol,SMB1Protocol-Client | Select-Object FeatureName,State"
FeatureName         State
-----------         -----
SMB1Protocol        Disabled
SMB1Protocol-Client Disabled

Qué significa: SMB1 está deshabilitado, lo cual es bueno. Pero si estás hablando con un NAS antiguo que solo habla SMB1, esto fallará.

Decisión: Prefiere actualizar el NAS o habilitar SMB2/3. Habilita SMB1 solo como último recurso, temporalmente y detrás de controles de red estrictos.

Task 12: Borra unidades mapeadas obsoletas y reconecta limpio

cr0x@server:~$ net use
New connections will be remembered.

Status       Local     Remote                    Network
-------------------------------------------------------------------------------
OK           Z:        \\fileserver\finance       Microsoft Windows Network
The command completed successfully.

cr0x@server:~$ net use z: /delete
z: was deleted successfully.

cr0x@server:~$ net use z: \\fileserver\finance /persistent:no
The command completed successfully.

Qué significa: Estás forzando una configuración de sesión nueva. Esto ayuda cuando hay credenciales, sesiones obsoletas o mapeos muertos implicados.

Decisión: Si la reconexión falla con System error 53, sigues en capas de red/nombre/puerto. Si falla con System error 5, estás en tierra de permisos/autenticación.

Task 13: Inspecciona la caché DNS del cliente por respuestas obsoletas

cr0x@server:~$ ipconfig /displaydns | findstr /i fileserver
fileserver
    Record Name . . . . . : fileserver.corp.example
    Record Type . . . . . : 1
    Time To Live  . . . . : 120
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 10.20.30.40

Qué significa: La estación de trabajo cacheó una IP. Si esa caché está mal, Windows seguirá fallando hasta que expire el TTL o lo vacíes.

Decisión: Si la IP cacheada es incorrecta, vacía la caché y arregla el DNS ascendente para que el problema no vuelva a aparecer.

Task 14: Vacía DNS y reintenta

cr0x@server:~$ ipconfig /flushdns
Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Qué significa: Eliminaste entradas DNS cacheadas. Si la resolución de nombres estaba obsoleta, esto puede arreglar el problema inmediatamente para ese cliente.

Decisión: Si vaciarlo lo arregla, aún necesitas preguntar por qué cambió el DNS y por qué las cachés estaban obsoletas (actualizaciones de registros, scavenging, múltiples servidores DNS).

Task 15: Verifica Kerberos/DNS desde el cliente (entornos de dominio)

cr0x@server:~$ klist
Current LogonId is 0:0x3e7

Cached Tickets: (2)
#0>     Client: user@CORP.EXAMPLE
        Server: krbtgt/CORP.EXAMPLE@CORP.EXAMPLE
        End Time: 2/5/2026 18:12:03
#1>     Client: user@CORP.EXAMPLE
        Server: cifs/fileserver.corp.example@CORP.EXAMPLE
        End Time: 2/5/2026 18:12:03

Qué significa: Tienes un ticket CIFS para el servidor de archivos. Eso generalmente indica que la resolución de nombres y la autenticación de dominio funcionan.

Decisión: Si no hay ticket cifs/ y fallas repetidamente, investiga SPNs, desajuste de tiempo o bloqueo de NTLM por política.

Task 16: Revisa los eventos del cliente SMB para un error más preciso

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-SMBClient/Operational' -MaxEvents 5 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-List"
TimeCreated      : 2/5/2026 9:09:41 AM
Id               : 30805
LevelDisplayName : Error
Message          : The SMB client failed to connect to the share. Error: The network path was not found.

Qué significa: El cliente SMB confirma la falla. A menudo, eventos cercanos incluyen detalles de negociación, signing o autenticación.

Decisión: Si ves errores de negociación o requisitos de signing, alinea las políticas SMB cliente/servidor. Si solo ves “path not found”, vuelve a las comprobaciones de nombre/puerto/servicio.

Task 17: En el servidor, confirma que la ruta del recurso existe en disco

cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'D:\Shares\Finance'"
True

Qué significa: El directorio subyacente existe. Si esto es False, el recurso puede existir pero apuntar a la nada (o el volumen no está montado).

Decisión: Si la ruta falta, investiga almacenamiento: montaje fallido, iSCSI desconectado, disco de clúster offline, destino DFS roto o volumen NAS no exportado.

Task 18: Revisa referencias DFS cuando el “servidor” es en realidad DFS

cr0x@server:~$ powershell -NoProfile -Command "dfsutil /pktinfo"
PKT Entry: \\corp.example\dfs\finance
  Referrals:
    \\fs01.corp.example\finance  (ACTIVE)
    \\fs02.corp.example\finance  (INACTIVE)

Qué significa: DFS está en juego. Un objetivo o referencia rota puede aparecer como “ruta de red no encontrada”, especialmente si los clientes son referidos a un nodo offline.

Decisión: Arregla la salud del objetivo DFS, deshabilita el objetivo muerto o corrige el costing por sitio. No culpes a “la red” cuando DFS está dando direcciones malas.

Broma #2: “Ruta de red no encontrada” es la forma de Windows de decir “Fui a la puerta, pero el edificio o desapareció o está cerrado—buena suerte.”

Errores comunes: síntoma → causa raíz → corrección

Esta sección es directa porque los mismos errores se repiten en cada empresa con una cola de tickets de helpdesk y una ventana de cambios.

1) Síntoma: El nombre falla, la IP funciona

Causa raíz: Registro A de DNS apunta a servidor antiguo; caché obsoleta; sufijo DNS equivocado; split-brain DNS entre on‑prem y VPN.
Corrección: Corrige registros DNS (y scavenging), vacía caché cliente, verifica que los clientes usen los servidores DNS correctos y deja de depender de broadcasts de NetBIOS.

2) Síntoma: Funciona en LAN de oficina, falla en VPN

Causa raíz: Split tunneling de VPN excluye subredes de servidores de archivos; firewall de VPN bloquea 445; DNS sobre VPN devuelve vista equivocada.
Corrección: Rutea la subred del servidor de archivos sobre la VPN, permite TCP 445 hacia servidores aprobados y alinea la vista DNS con la ruta de acceso.

3) Síntoma: De repente falla para todos tras un “endurecimiento de seguridad”

Causa raíz: GPO deshabilita cliente SMB, bloquea NTLM, exige SMB signing o desactiva acceso de invitado; cambios de firewall bloquean SMB entrante.
Corrección: Revertir o ajustar la política con una lista de excepciones controlada; validar signing/NTLM en ambos extremos; probar con un grupo piloto.

4) Síntoma: Solo falla un recurso; otros en mismo servidor funcionan

Causa raíz: Recurso renombrado, eliminado o apunta a un volumen ausente; objetivo DFS roto; permiso a nivel de recurso removido.
Corrección: Confirma que el recurso existe en el servidor, verifica la ruta del recurso, restaura el montaje del volumen o corrige el objetivo/referral de DFS.

5) Síntoma: Servidor accesible, pero Explorador muestra vacío / gran demora y luego error

Causa raíz: Negociación SMB se atasca por desajuste de signing/encriptación; antivirus/seguridad intercepta SMB; middleboxes de red que manipulan paquetes.
Corrección: Revisa logs SMB cliente/servidor, evita la inspección temporalmente para pruebas, valida dialectos SMB soportados y confirma MTU/fragmentación razonable.

6) Síntoma: NAS antiguo inaccesible tras una actualización de Windows

Causa raíz: NAS solo soporta SMB1; la actualización de Windows removió/deshabilitó el cliente SMB1.
Corrección: Actualiza firmware/configuración del NAS a SMB2/3. Si es imposible, aísla ese NAS y habilita SMB1 cliente solo en máquinas necesarias temporalmente.

7) Síntoma: “Ruta no encontrada” intermitente, especialmente en almacenamiento en clúster

Causa raíz: Disponibilidad continua SMB no realmente disponible; failovers del clúster rompen sesiones; fallos en almacenamiento backend desmontan volúmenes.
Corrección: Valida roles de clúster y configuración de recursos, revisa estabilidad multipath/iSCSI y monitorea eventos de failover correlacionados con reportes de usuarios.

Tres micro-historias corporativas (cómo falla esto en la vida real)

Micro-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana migró su servidor de archivos a una nueva VM. Mismo hostname, nueva IP, “sin problema.” El equipo actualizó DNS y probó desde
un par de escritorios de TI. Todos se fueron a casa.

A las 8:30 a.m., el helpdesk empezó a ver 0x80070035 en múltiples departamentos. No en todos. Justo los suficientes para causar pánico.
El ingeniero on‑call supuso “la nueva VM está caída” y reinició el servicio SMB. Sin cambios. Luego reinició la VM. Aún sin cambios.

La causa fue dolorosamente simple: dos servidores DNS. Uno recibió el registro A actualizado. El otro no replicó correctamente y seguía sirviendo la IP vieja.
Las estaciones estaban configuradas con ambos DNS, así que la resolución dependía de cuál respondía primero. El servidor de archivos no estaba caído;
a la mitad de los clientes los enviaban a una dirección muerta.

La solución fue corregir la replicación y forzar la transferencia de zona, luego vaciar las cachés de los clientes. La lección fue más importante que la solución:
“DNS actualizado” no es una afirmación. Es una hipótesis que necesita prueba desde múltiples resolutores.

Micro-historia 2: La optimización que salió mal

Otra organización tenía un proyecto de “reducción de latencia”. Alguien notó que el tráfico SMB hacía hairpin a través de un firewall central cuando las sucursales
accedían al clúster de archivos del HQ. La solución propuesta: añadir una nueva política de firewall que bloqueara SMB desde subredes no aprobadas y
forzar a las sucursales a usar un servicio de caché local.

El despliegue del servicio de caché se retrasó, pero el cambio de firewall se aplicó según lo programado porque era “seguro”: después de todo, la mayoría del SMB no debería
salir del HQ. La solicitud de cambio incluso incluía una lista de subredes “permitidas”.

Al mediodía, ingeniería no podía acceder a artefactos de build en \\buildshare. Finanzas no podía acceder a hojas de cálculo de fin de mes. El error
no era “bloqueado por política.” Era 0x80070035. Los clientes Windows no describen tus cambios de firewall; simplemente fallan.

Causa raíz: la lista permitida no incluía un pool de direcciones VPN usado por personal remoto ni un conjunto de VLANs Wi‑Fi nuevas. La “optimización” era
correcta en espíritu pero se desplegó en el orden equivocado y sin telemetría para flujos 445 denegados.

La solución no fue solo añadir subredes. Implementaron despliegues por fases con logging de denegaciones, paneles centrados en bloqueos TCP 445 y un cliente canario
en cada segmento de red importante. La moraleja: optimiza al final, después de poder ver lo que rompes.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una gran empresa operaba namespaces DFS para los recursos de usuarios con múltiples objetivos por sitio. No era emocionante. No era moderno. Era
consistente, documentado y probado trimestralmente. El equipo de almacenamiento mantenía una runbook simple: validar salud de referencias DFS, validar escucha SMB,
validar rutas de recursos y validar volúmenes backend.

Una mañana, un bug de firmware en una matriz de almacenamiento provocó que un subconjunto de LUNs cayera momentáneamente. En dos servidores de archivos, el volumen
que alojaba un recurso crítico volvió con una letra de unidad diferente debido a un cambio en el orden de montaje. El recurso seguía existiendo en el SO, pero apuntaba a una
ruta vacía. Los clientes recibieron “ruta de red no encontrada” de forma intermitente dependiendo de a qué objetivo DFS eran referidos.

El ingeniero on‑call no adivinó. Siguió la runbook. Primero: Test-NetConnection 445 (bien). Segundo: Get-SmbShare en ambos objetivos
(el recurso existe). Tercero: Test-Path en la ruta del recurso (falso en dos nodos). Cuarto: arreglar los puntos de montaje y validar.

El tiempo de outage fue limitado porque alguien hizo el trabajo aburrido antes: monitorización consistente de objetivos DFS y el hábito de comparar rutas de recursos
con montajes de almacenamiento. Nada de heroísmos. Nada de poesía en Slack a medianoche. Solo un sistema que falla de formas conocidas y un equipo que reconoce el patrón.

Datos interesantes e historia breve (SMB, redes Windows y por qué sufrimos)

Dato 1: SMB se originó en IBM en los años 80 y luego fue adoptado y extendido por Microsoft; es más antiguo que muchos planes de “modernización” en producción.
Dato 2: Las redes Windows históricamente dependieron de NetBIOS y resolución por broadcast—cómodo en LAN planas, problemático en redes encaminadas.
Dato 3: TCP 445 (“SMB sobre TCP”) redujo la dependencia de NetBIOS sobre TCP 139, pero muchos entornos aún arrastran suposiciones heredadas de la era 139.
Dato 4: Las debilidades de SMB1 se hicieron tan famosas que Windows moderno deshabilita SMB1 por defecto; esto rompe dispositivos NAS antiguos exactamente como predices.
Dato 5: La misma ruta UNC puede atravesar pilas distintas: SMB directo, namespaces DFS o incluso WebDAV en algunas configuraciones—cada uno con modos de fallo distintos.
Dato 6: Los errores del Explorador de Windows a menudo colapsan fallos subyacentes múltiples en un mensaje genérico; los registros de eventos suelen ser más específicos.
Dato 7: SMB signing y cifrado mejoran integridad/seguridad pero pueden causar fallos de negociación cuando cliente y servidor tienen políticas desalineadas.
Dato 8: “Network Location Awareness” (NLA) influye en los perfiles de firewall; una clasificación equivocada a Public puede bloquear tráfico de compartición silenciosamente.
Dato 9: Las referencias DFS pueden cambiar según el mapeo de sitios/subredes en AD; un mapeo de sitio incorrecto puede enviar clientes a objetivos lejanos o muertos.

Listas de verificación / plan paso a paso (para personas bajo presión)

Checklist A: Un usuario reporta 0x80070035

Pide que prueben la ruta por IP: \\10.20.30.40\share. Si funciona, es resolución de nombres.
En el cliente: ejecutar Test-NetConnection server -Port 445. Si falla, es red local/VPN/política.
Quitar mappings: net use * /delete (con cuidado) o elimina la unidad específica y luego reconecta.
Vaciar caché DNS: ipconfig /flushdns.
Comprobar perfil: Get-NetConnectionProfile. Si está en Public, arregla la clasificación de red.
Extraer eventos del registro SMBClient Operational alrededor de la hora de fallo.

Checklist B: Todo el equipo no puede acceder a un recurso

Confirma que el recurso existe en el servidor: Get-SmbShare o lista de recursos del NAS.
Confirma que la ruta del recurso existe: Test-Path en el servidor; verifica puntos de montaje/volúmenes.
Confirma servicio SMB y puerto en escucha en el servidor: Get-Service LanmanServer, Get-NetTCPConnection -LocalPort 445.
Revisa cambios en políticas de firewall y logs de denegación para el puerto 445.
Si es DFS: valida referencias y salud de objetivos; deshabilita objetivos muertos.

Checklist C: “Funcionaba ayer” tras parches o despliegue de políticas

Revisa si cambiaron políticas SMB1/guest/NTLM en clientes o servidores.
Valida que requisitos de SMB signing coincidan en ambos extremos.
Revisa reglas de Firewall de Windows bajo “File and Printer Sharing”.
Compara una máquina que funciona vs una que falla: servidores DNS, postura VPN, categoría de red y versiones de agentes de seguridad.
Revierte la política si no puedes demostrar que el cambio es benigno.

Preguntas frecuentes

Q1: ¿0x80070035 es lo mismo que “System error 53”?

Están estrechamente relacionados. net use a menudo reporta problemas de conectividad/nombre/ruta como “System error 53 has occurred. The network path was not found.”
El Explorador puede mostrar 0x80070035 para la misma clase de fallo subyacente.

Q2: ¿Por qué a veces usar la IP funciona cuando el hostname falla?

Porque evitas DNS y cualquier capa de resolución de nombres (sufijo DNS, WINS/NetBIOS, fallback en caché). Si la IP funciona, tu transporte está bien.
Arregla el nombrado, no los firewalls.

Q3: ¿Qué puerto necesito abrir para compartidos SMB?

SMB moderno usa TCP 445. NetBIOS/SMB legado puede involucrar 137–139, pero deberías usar 445 para Windows y NAS soportados.
Si 445 está bloqueado, espera 0x80070035 u errores similares.

Q4: ¿Los permisos pueden causar 0x80070035?

Normalmente los problemas de permisos aparecen como “Access denied”, solicitudes de credenciales o errores de autenticación específicos. Pero los bloqueos por política (como “deny NTLM”)
pueden manifestarse como fallos genéricos. Revisa logs SMBClient y registros de seguridad del servidor para estar seguro.

Q5: ¿Por qué falla solo desde casa o solo en VPN?

El enrutamiento de VPN y reglas de firewall son los culpables habituales. El split tunneling puede excluir la subred del servidor de archivos y algunos perfiles de seguridad VPN bloquean 445 por defecto.
Confirma con Test-NetConnection -Port 445 desde el cliente mientras está en VPN.

Q6: ¿Debería habilitar SMB1 para arreglar esto rápidamente?

Solo si confirmaste que el servidor/NAS soporta únicamente SMB1 y no puedes actualizar inmediatamente. Habilitar SMB1 amplía la superficie de ataque.
Trátalo como un puente temporal con contención, no como solución permanente.

Q7: ¿Y si ping funciona pero SMB no?

Ping demuestra alcance ICMP, no alcance de aplicación. Los firewalls a menudo permiten ICMP pero bloquean TCP 445. O el servicio SMB no está en ejecución.
Prueba 445 explícitamente y revisa el estado de escucha del servidor.

Q8: ¿Y si 445 conecta pero el recurso aún dice “no encontrado”?

Entonces ya pasaste el enrutamiento/firewall y estás en territorio SMB/recurso/DFS: nombre de recurso incorrecto, recurso eliminado, ruta de recurso faltante, referral DFS roto
o desajuste de negociación/política que registra más detalle que el Explorador.

Q9: ¿Cómo sé si DFS está involucrado?

Si la ruta se ve como \\domain\dfsroot\share, eso es DFS. Usa dfsutil /pktinfo para ver a qué objetivo te referenciaron.
Un objetivo de referencia muerto puede hacer que la ruta parezca “no encontrada”.

Q10: ¿Por qué Windows a veces muestra errores diferentes para el mismo problema?

Componentes diferentes exponen abstracciones distintas: el Explorador, el cliente SMB, el redirector, el gestor de credenciales y DFS tienen sus propios mapeos de errores.
Confía en la realidad a nivel de paquete (¿puedes conectar al 445?) y en los registros de eventos más que en el texto de la GUI.

Conclusión: próximos pasos prácticos

0x80070035 no es místico. Es un fallo por capas: resolución de nombres, conectividad a TCP 445, disponibilidad del servicio SMB, existencia del recurso y luego auth/política.
La solución más rápida es la desmentida más rápida—prueba IP, verifica 445, valida que el recurso exista y lee los logs que no edulcoran.

Pasos siguientes que puedes tomar hoy:

Crea una runbook de una página a partir de la “Guía de diagnóstico rápido” y colócala donde tu on‑call realmente la vea.
Monitorea y alerta sobre denegaciones TCP 445 en los límites de red (con correlación de cambios), no solo gráficos de CPU del servidor.
Inventaría versiones SMB en NAS/servidores de archivos; elimina dependencias de SMB1 antes de la próxima oleada de endurecimiento de Windows que las elimine por ti.
En entornos DFS: valida regularmente referencias y elimina objetivos muertos. DFS es genial hasta que educadamente dirige a los usuarios a ninguna parte.
Estandariza una prueba canaria desde cada segmento de red (LAN, VPN, VLAN Wi‑Fi) que compruebe resolución de nombres y conectividad 445 a recursos críticos.