"Failed to retrieve share list from server" error when browsing a share with Nautilus

A bit before upgrading from 10.04 to 11.10, my Ubuntu desktop stopped allowing me to access my Windows share directories. I figured I'd upgrade to 11.10 and the problem would get fixed but no.

Whenever I click on a Windows network domain using Nautilus, the following message pops up.:

Unable to mount location - Failed to retrieve share list from server

Where do I start troubleshooting this problem? I am getting desperate now :(

I tried

sudo mount -t cifs //SomeMachine/SomeShare some_directory

and I get

mount error(115): Operation now in progress

Strangely enough, I got a popup stating:

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

Solution 1:

I found this advice from Gord Nickerson worked for me: The error message is 'failed to retrieve share list from server' so it cannot browse a Windows 7 pc or a Ubuntu 10 pc or a mac desktop pc.

First of all, the Samba daemons smbd and nmbd must both be running for network browsing to work. They can be started with service, or with systemctl start for the newer systemd-based releases of Ubuntu.

smbtree lists all the shares from machines on the network.

So, off to /etc/samba and we sudo pico smb.conf.

The name resolve order uses hosts files first and broadcasts last and it is commented out! Maybe we change that to:

name resolve order = bcast host

and then restart the servers with service smbd restart and service nmbd restart

Works! This is an awful mistake to make in an upgrade. Upgrade should not break what is working, particularly something as important as networking. Good thing i recall the manual work you had to do to get samba working back in redhat 5 and 6.

Solution 2:

This is the true answer of your question. I also had the same problem.

Run terminal and enter this command

gksudo gedit /etc/hosts

and add computer ip address and name in hosts file. Save and exit.

Sample ip and name:

192.168.120.65    blablaPcName

Thats all.

Solution 3:

The problem (at least in Ubuntu 18.04 where I tried it) is that the following command:

sudo ufw allow Samba

will only add rules for Samba acting as a server. It will not add any rules for Samba acting as a client. But when you try to mount a remote share, that's what you are doing: in this scenario your machine is a client, and the remote machine is a server.

Also, the "no reply" error is a hint that some firewall is messing things up. Machines do generally respond to requests. They may respond with an error, in which case you have other problems, but if they don't respond at all, then their packets are usually being eaten up by a firewall.

The rules that allow Samba to act as a server are not sufficient to also allow Samba to act as a client, because the remote machines respond from their own port 137, but the local port on which these responses arrive is not 137, it is some random port.

To solve this problem, execute the following command:

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

This will allow UDP packets to arrive into any local port as long as they are originating from port 137 or 138 of the remote computer. The port 138 is probably not necessary, as I have only seen packets arriving from 137, but you never know.

This is probably insecure, because the originating port can be spoofed, but let's not be paranoid.

This fixed it for me.