Error "Error al recuperar la lista de recursos compartidos del servidor" al explorar un recurso compartido con Nautilus

Un poco antes de actualizar de 10.04 a 11.10, mi escritorio Ubuntu dejó de permitirme acceder a mis directorios compartidos de Windows. Pensé que actualizaría a 11.10 y el problema se solucionaría, pero no.

Cada vez que hago clic en un dominio de red de Windows usando Nautilus, aparece el siguiente mensaje:

No se puede montar la ubicación: no se pudo recuperar la lista compartida del servidor

¿Dónde empiezo a solucionar este problema? Me estoy desesperando ahora :(

Lo intenté

sudo mount -t cifs //SomeMachine/SomeShare some_directory

y consigo

mount error(115): Operation now in progress

Por extraño que parezca, recibí una ventana emergente que decía:

Could not display network:/// Error: Dbus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply ...

Esta es la verdadera respuesta de tu pregunta. También tuve el mismo problema.

Ejecute la terminal e ingrese este comando

gksudo gedit /etc/hosts

y agregue la dirección IP y el nombre de la computadora en el archivo de hosts. Guardar y Salir.

IP de muestra y nombre:

192.168.120.65    blablaPcName

Eso es todo.

Encontré que este consejo de Gord Nickerson funcionó para mí: el mensaje de error es "no se pudo recuperar la lista de recursos compartidos del servidor", por lo que no puede examinar una PC con Windows 7 o una PC con Ubuntu 10 o una PC de escritorio Mac.

En primer lugar, los demonios Samba smbdy nmbdambos deben estar ejecutándose para que funcione la navegación en red. Se pueden comenzar con service, o con systemctl startlas versiones más recientes basadas en systemd de Ubuntu.

smbtree enumera todos los recursos compartidos de las máquinas en la red.

Entonces, fuera /etc/sambay nosotros sudo pico smb.conf.

¡El orden de resolución de nombres usa primero los archivos de host y las últimas transmisiones y está comentado! Tal vez cambiemos eso a:

name resolve order = bcast host

y luego reinicie los servidores con service smbd restartyservice nmbd restart

¡Trabajos! Es un error terrible cometer una actualización. La actualización no debe romper lo que funciona, particularmente algo tan importante como la creación de redes. Lo bueno es que recuerdo el trabajo manual que tuvo que hacer para que la samba volviera a funcionar en redhat 5 y 6.

Es posible que este sea un error general al conectarse al sistema:

• http://forums.gentoo.org/viewtopic-t-895820-start-0.html

En el caso del hilo anterior, hubo una falta de coincidencia entre el nombre y la dirección IP, y nmblookupayudó a determinar el problema. Además, esta página parece tener algunos buenos consejos de solución de problemas

• http://www.linuceum.com/Server/srvSambaTrouble.php

Que estoy copiando:

• Ponga smbclient en modo de depuración, la salida debería aparecer en dmesg (-d | --debuglevel = level)
• smbclient -L //<IP of Samba Server> -U <server user>
• nmblookup {name}
• ¿Se puede montar desde otros sistemas?

Edita tu pregunta si haces más solución de problemas.

Con Ubuntu 14.04:

Este error puede ser causado por un nombre de netbios que tiene un tamaño superior a 15 caracteres. Debería generar registros en el archivo /var/log/samba/log.smbd con este aspecto:

register_name: NetBIOS name NAME-OF-PC-TOO-LONG is too long. Truncating to

Este error se puede solucionar editando el archivo /etc/samba/smb.conf y agregando la siguiente línea:

netbios name = NAME-OF-PC

NAME-OF-PC no tendrá más de 15 caracteres.

He tenido muy buenos resultados en entornos de redes mixtas (Windows / Ubuntu) con este método:

1. Presione Alt+ F2y escriba:gksu gedit /etc/nsswitch.conf

2. Busque esta línea:

   hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4
   

3. Agregar winspara que se vea así:

   hosts:  files mdns4_minimal [NOTFOUND=return] wins dns mdns4
   

4. Instale el paquete "winbind": sudo apt-get install winbind

   (O a través del Centro de software o Synaptic ).

5. Reinicie o reinicie su red.

Simplemente agregue "permitir" al firewall:

• Puerto 137 / UDP: utilizado por nmbd
• Puerto 138 / UDP: utilizado por nmbd
• Puerto 139 / TCP: utilizado por smbd
• Puerto 445 / TCP: utilizado por smbd

Y funcionará, y si no sabe cómo hacerlo, simplemente instale "gufw" y use el "+" y luego la "pestaña simple".

Mi problema se debió a /etc/samba/smb.conf. Busqué WORKGROUPy eliminé la línea que mencionaba un localhostnombre. Asegúrese de que WORKGROUPsea ​​el mismo para ambos archivos de configuración en cada máquina. Una forma completa es sudo apt-get purge samba(y / o remove?) Y luego sudo apt-get install samba. Así es como resuelvo el problema la primera vez, después de actualizar de 16.10 a 17.04 en una de mis máquinas (16.10 tenía errores). Tengo dos máquinas ahora: 16.04 y 17.04.

Tuve este problema y lo resolví instalando el paquete gvfs-bin . Excepto para gvfs-bin, la mayoría de los paquetes de gvfs ya estaban instalados: gvfs, -common, -libs, -daemons y -backends.

Intente iniciar sesión en un cuadro de Windows desde Ubuntu usando Archivos. Vaya a "Otras ubicaciones" y "Conectar al servidor" en la parte inferior. Use smb: // username @ serveraddress. Esto funcionó para mí.

El problema (al menos en Ubuntu 18.04 donde lo probé) es que el siguiente comando:

sudo ufw allow Samba

solo agregará reglas para que Samba actúe como servidor. No agregará ninguna regla para que Samba actúe como cliente. Pero cuando intenta montar un recurso compartido remoto, eso es lo que está haciendo: en este escenario, su máquina es un cliente y la máquina remota es un servidor.

Además, el error "sin respuesta" es una pista de que algún firewall está estropeando las cosas. Las máquinas generalmente responden a las solicitudes. Es posible que respondan con un error, en cuyo caso usted tiene otros problemas, pero si no responden en absoluto, entonces sus paquetes generalmente están siendo consumidos por un firewall.

Las reglas que permiten que Samba actúe como servidor no son suficientes para permitir también que Samba actúe como cliente, porque las máquinas remotas responden desde su propio puerto 137, pero el puerto local al que llegan estas respuestas no es 137, es algo puerto aleatorio

Para resolver este problema, ejecute el siguiente comando:

sudo ufw allow in proto udp from any port 137,138 to any

Esto permitirá que los paquetes UDP lleguen a cualquier puerto local siempre que se originen en el puerto 137 o 138 de la computadora remota. El puerto 138 probablemente no sea necesario, ya que solo he visto paquetes que llegan desde 137, pero nunca se sabe.

Esto probablemente sea inseguro, porque el puerto de origen puede ser falsificado, pero no seamos paranoicos.

Esto me lo arregló.

Solo pude ver mi servidor samba por dirección ip.

Cambiando bcast a 1er en 'nombre resolver orden = bcast lmhosts hosts gana'. Y reiniciando samba. Por cierto, esta línea 1 reinicia samba.

sudo service samba restart

Eso tampoco funcionó.

Fui a buscar /etc/samba/lmhostspara comprobarlo y no hay archivo! Entonces hice lmhosts.

$ sudo nano /etc/samba/lmhosts   
10.0.2.2   server_name 

Todavía no pude buscar el nombre del servidor. Entonces pensé esperar, el nombre de la computadora y el nombre de samba son diferentes. Así que edité hosts y hostname, cambiándolos por el nombre del servidor samba. El nombre de host cuidadoso solo tiene una palabra. El nombre de la computadora no # comentarios.

/etc/hosts    
/etc/hostname    
$ sudo reboot 

Ahora simplemente funciona. ¡Solo puedo hacer clic en la red en nautilus o caja y el servidor simplemente aparece! En todos los clientes, todos son Linux o Android. Incluso en una vieja máquina exprimidora Debian.