En un servidor corriendo Windows Server 2003 que debía montar unas unidades de red NFS, me topé con el siguiente caso:
Si ahí terminara la cosa, sería una buena justificación para culpar al NFS, pero lo mas raro es el otro síntoma:
Las primeras pruebas realizadas -sin éxito- fueron tan básicas como crear un nuevo perfil de usuario y verificar que el servicio "Estación de trabajo" esté iniciado. Luego de algunas búsquedas de problemas similares, intenté verificar la negociación de versión de NFS y descartar alguna que algún recurso NFS accedido anteriormente haya dejado una configuración residual de AnonymousUID o AnonymousGID en el registro. Llegué a intentar soluciones tan desesperadas como tratar de engañar al Windows con un enlace simbólico al NFS.
Era hora de utilizar la famosa premisa que repite Mark Russinovich en cada una de sus sesiones "The case of the unexplained": Ante la duda, ejecuta Process Monitor.
Ejecuto Process Monitor y dejo corriendo las trazas sin filtros, intento montar con net use el NFS share y con la función find de Process Monitor busco la cadena de texto correspondiente a la dirección IP del servidor NFS. Aquí encuentro la primera pista útil, en el path que llama el proceso explorer puede verse una cadena de texto extraña en la ruta del export NFS, con un resultado de BAD_NETWORK_NAME.
Comparando esta traza con otra tomada en un sistema que funciona correctamente se comprueba que desde luego, esa cadena de texto es completamente anormal. Otra busqueda revela que RDPNP, que es el lo que se agrega al path del NFS, es un proveedor de red controlado por la librería mpr.dll (Multiple Provider Router):
Technet - Multiple Provider Router:
Curioso por conocer la evidente diferencia entre los mecanismos para acceder a un recurso de red mediante net use y acceder mediante el menú ejecutar, y ya con la librería mpr.dll ya en la mira, le dí una revisión al libro de Mark Russinovich "Windows Internals: 6th Edition", un libro "viejo" para los estándares de los libros de IT (Basado en Windows Vista y Server 2008), pero aún así vigente en su mayor parte. El siguiente diagrama muestra que hay dos vías para llegar a un recurso de red NFS, via el Multiple Provider Router o vía User Mode.
Esto explica porque es posible acceder al NFS share vía el menú ejecutar pero no es posible montarlo, pero aún no resuelve el problema. El siguiente paso fué un sfc /scannow seguido de una verificación del hash del archivo mpr.dll y posteriormente compararlo con el mismo archivo en otro servidor funcional. También se compararon permisos entre ambos archivos, lectura y ejecución, todo se ve normal en el archivo en sí.
Paso al registro, toca revisar los Network Providers, estos son unos mini-redirectores proveídos por Microsoft o terceros para acceder a servicios de Red como SMB, NFS, Unidades compartidas mediante Terminal Server y WebDav, estos redirectores están seteados en la clave del registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder, usualmente deben verse como en la siguiente imagen:
En el sistema afectado esta clave tiene un solo provider, correspondiente al componente SnacNP del fabricante Symantec:
Mientras que en otro sistema funcional se ve que el SnacNP se antepone a los demas providers:
Al intentar desinstalar el software encuentro que el mismo ya no está presente en el sistema, lo cual es bueno, pero evidentemente su instalación/desinstalación fue errática, ya que cuando fue instalado el SnacNP de Symantec sobrescribió completamente el valor existente en este sistema, en lugar de simplemente agregar la cadena de texto necesaria.
Otra curiosidad es que al intentar agregar los providers manualmente desde Centro de Redes y Recursos Compartidos > Configuración del Adaptador > Configuración avanzada, había una pestaña ausente:
- Al intentar mapear un NFS export desde el explorador de Windows se recibe el error “Network Path not found”. Lo mismo sucede con los comandos net use y mount.
Si ahí terminara la cosa, sería una buena justificación para culpar al NFS, pero lo mas raro es el otro síntoma:
- Al escribir la ruta de red desde el menú ejecutar, se puede acceder al export NFS correctamente, aunque se siente algo de lentitud al recorrer directorios o copiar archivos.
Las primeras pruebas realizadas -sin éxito- fueron tan básicas como crear un nuevo perfil de usuario y verificar que el servicio "Estación de trabajo" esté iniciado. Luego de algunas búsquedas de problemas similares, intenté verificar la negociación de versión de NFS y descartar alguna que algún recurso NFS accedido anteriormente haya dejado una configuración residual de AnonymousUID o AnonymousGID en el registro. Llegué a intentar soluciones tan desesperadas como tratar de engañar al Windows con un enlace simbólico al NFS.
Era hora de utilizar la famosa premisa que repite Mark Russinovich en cada una de sus sesiones "The case of the unexplained": Ante la duda, ejecuta Process Monitor.
Ejecuto Process Monitor y dejo corriendo las trazas sin filtros, intento montar con net use el NFS share y con la función find de Process Monitor busco la cadena de texto correspondiente a la dirección IP del servidor NFS. Aquí encuentro la primera pista útil, en el path que llama el proceso explorer puede verse una cadena de texto extraña en la ruta del export NFS, con un resultado de BAD_NETWORK_NAME.
Comparando esta traza con otra tomada en un sistema que funciona correctamente se comprueba que desde luego, esa cadena de texto es completamente anormal. Otra busqueda revela que RDPNP, que es el lo que se agrega al path del NFS, es un proveedor de red controlado por la librería mpr.dll (Multiple Provider Router):
Technet - Multiple Provider Router:
The Multiple Provider Router (MPR) handles communication between the Windows operating system and the installed network providers. It enables Windows to present an integrated network to the user.When the MPR starts, it checks the registry to determine which network providers are installed on the system and the order they should be cycled through. It loads all registered network provider DLLs and uses them to process subsequent WNet calls made by the user interface or other applications.
Esto explica porque es posible acceder al NFS share vía el menú ejecutar pero no es posible montarlo, pero aún no resuelve el problema. El siguiente paso fué un sfc /scannow seguido de una verificación del hash del archivo mpr.dll y posteriormente compararlo con el mismo archivo en otro servidor funcional. También se compararon permisos entre ambos archivos, lectura y ejecución, todo se ve normal en el archivo en sí.
Paso al registro, toca revisar los Network Providers, estos son unos mini-redirectores proveídos por Microsoft o terceros para acceder a servicios de Red como SMB, NFS, Unidades compartidas mediante Terminal Server y WebDav, estos redirectores están seteados en la clave del registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder, usualmente deben verse como en la siguiente imagen:
En el sistema afectado esta clave tiene un solo provider, correspondiente al componente SnacNP del fabricante Symantec:
Mientras que en otro sistema funcional se ve que el SnacNP se antepone a los demas providers:
Al intentar desinstalar el software encuentro que el mismo ya no está presente en el sistema, lo cual es bueno, pero evidentemente su instalación/desinstalación fue errática, ya que cuando fue instalado el SnacNP de Symantec sobrescribió completamente el valor existente en este sistema, en lugar de simplemente agregar la cadena de texto necesaria.
Otra curiosidad es que al intentar agregar los providers manualmente desde Centro de Redes y Recursos Compartidos > Configuración del Adaptador > Configuración avanzada, había una pestaña ausente:
Mientras que en un servidor sano vemos lo siguiente:
Finalmente el problema se corrigió editando el registro y agregando las cadenas faltantes (LanmanWorkstation, RDPNP y Nfsclientnp) al registro. Con esto ya apareció la pestaña de Network Providers que no se veía anteriormente, se logró montar la unidad NFS y la performance del recorrido por los directorios mejoró notablemente.
Por último, dejo algunos enlaces interesantes sobre el uso de las herramientas de sysinternals para troubleshooting en Windows:
- Utilizing SysInternals Tools for IT Pros
- Windows Sysinternals Primer: Process Explorer, Process Monitor, and More
- Case of the unexplained: Windows troubleshooting with Mark Russinovich
- Malware Hunting with the Sysinternals Tools
- License to Kill: Malware Hunting with the Sysinternals Tools
- Windows Internals, Part 1: System architecture, processes, threads, memory management, and more (7th Edition)
- Troubleshooting with the Windows Sysinternals Tools (2nd Edition)
