Connect to smb server by name doesn't work, but by IP address does

Bug #235560 reported by Andy Stallwood on 2008-05-28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
samba (Debian)
Fix Released
samba (Ubuntu)

Bug Description

Connect to Server... doesn't let me connect to my windows share by server name, but works fine by IP address.

The error message displayed is "Couldn't display "smb://buffalo/temp". There is no application for this file type" (see Screenshot-nautilus.png).

If I map by IP address, then it works OK. My machine can ping the server by name, so it's resolving it no problem.

Can you help?


andy@andy-laptop:~$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

andy@andy-laptop:~$ apt-cache policy gvfs
  Installed: 0.2.4-0ubuntu1
  Candidate: 0.2.4-0ubuntu1
  Version table:
 *** 0.2.4-0ubuntu1 0
        500 hardy-proposed/main Packages
        100 /var/lib/dpkg/status
     0.2.3-0ubuntu5 0
        500 hardy-updates/main Packages
     0.2.3-0ubuntu4 0
        500 hardy/main Packages

andy@andy-laptop:~$ apt-cache policy nautilus
  Installed: 1:2.22.2-0ubuntu6
  Candidate: 1:2.22.2-0ubuntu6
  Version table:
 *** 1:2.22.2-0ubuntu6 0
        500 hardy-updates/main Packages
        100 /var/lib/dpkg/status
     1:2.22.2-0ubuntu4 0
        500 hardy/main Packages

Andy Stallwood (andy-stallwood) wrote :
Brian Murray (brian-murray) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. If you go to Places -> Network -> Windows Network can you find your server and the share you are trying to access? Thanks in advance.

Andy Stallwood (andy-stallwood) wrote :

Hi Brian,
Thanks for your time on this, so far.

Yes, I can find the server, and the share, but then when I double click on it, it gives the same error as above "Couldn't display "smb://buffalo/temp". There is no application for this file type" (see Screenshot-nautilus.png).

I know my machine is able to resolve the server name to an IP, as I can ping by name, and map using /etc/fstab by name as well.



Andy Stallwood (andy-stallwood) wrote :

I can also replicate the problem by typing smb://buffalo/ibmbackup in the location bar at the top of Nautilus, which gives the error "The folder contents could not be displayed. Sorry couldn't display all of the contents of "ibmbackup on buffalo": Connection timed out", which is a more likely error than the "no application" one above.

Typing in smb:// prompts immediately for a username and password, as expected, and then shows the contents of the share, once that info is entered.


Changed in nautilus:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

thank you for your bug report. does using smbclient on the server name work correctly? do you have some sort of firewall that could create the issue?

Changed in nautilus:
status: Confirmed → Incomplete
JimmyKang (james-king) wrote :

I have the no application issue also. sometimes it will work, sometimes not. Sometimes it will display the error and then still work for a little while.

I am new to Ubuntu so I have not intentionally installed any firewalls. However, I do not know if any come with the default install.

I don't ever have trouble listing the shared folders on a server. It is not until I drill into one of those folders that the problem arises.

JimmyKang (james-king) wrote :

Forgot to mention that I am using the 64 bit version.

Ed Comer (celem) wrote :

I also have this problem also on 32-bit Hardy, and have had it ever since an update in Dapper. Many others also have the problem - see posts at:

I previously reported this bug on with Bug 47386. The problem remains just as bad as ever on Hardy.

MikeK (michael-j-kirschner) wrote :

I had problem too. I stumbled upon a comment in that said put IP & HOST in /etc/hosts. I did and problem resolved. Not elegant but it gets around the issue.

Hi Seb,
I am running FireStarter, but it shows no blocked connections, and disabling it and the firewall on my debian smb server doesn't stop the problem. There is no hardware firewall on my internal network. My windows (sorry :-) ) machine doesn't have this problem.

Here is the output from smbclient (hopefully this is what you wanted)

andy@andy-laptop:~$ smbclient --list=buffalo

 Sharename Type Comment
 --------- ---- -------
 print$ Disk Printer Drivers
 andy Disk
 shared Disk
 jo Disk
 ibmbackup Disk
 IPC$ IPC IPC Service (buffalo server)
 LexmarkZ615 Printer Lexmark Z615 Colour Printer

 Server Comment
 --------- -------

 Workgroup Master
 --------- -------

Hi MikeK
Adding an entry into my hosts file doesn't resolve the issue for me. It still fails to connect.

Changed in nautilus:
status: Incomplete → New
Ed Comer (celem) wrote :

Re MikeK's comment - yes using the IP address usually works, but the reported problem is that the name or graphical solution is broken for many, if not most users. We shouldn't have to insert the IP address to use this feature.

Please forgive me if this is incorrect, but I want to see if this information helps others better troubleshoot this issue.

While researching the issue for my similar bug report, I found that having a DNS server that responds to otherwise invalid host entries (i.e. OpenDNS) may contribute. Removing all DNS servers from my network configuration seems to allow browsing the shares, but I'm still affected by other issues.


CoffeeBurrito (coffeeburrito) wrote :

I had the 100% exact same problem that Andy describes. However, for me it was not a problem with Nautilus at all, and just a misconfiguration of samba's name resolution.

The way I fixed it was
sudo gedit /etc/samba/smb.conf

Uncomment this line (remove the semicolon)
; name resolve order = lmhosts host wins bcast

and restart samba
sudo /etc/init.d/samba restart

For the record, I have it set up so netbios lookups are resolved through the DNS server.

Hi Brandon,
Thanks for the tip. I've removed the DNS server addresses from my config, and it hasn't made any difference.

Hi CoffeeBurrito (that doesn't sound like a very tasty snack :-) ),
I've tried this as well, sudo /etc/init.d/samba restart doesn't work (there is no samba in the /etc/init.d directory. I rebooted though, and I still have the same problem.



va9rant (va9rant-yahoo) wrote :

hello can confirm that this bug may be caused by settings in /etc/nsswitch.conf.

In my case, I have Hardy, installed with samba, firestarter (running at startup) and winbind.

adding the value "wins" in the line in /etc/nsswitch.conf:

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

causes the problem for me, removing "wins" from nsswithc.conf and logging out and logging on fixed the problem. i can again access samba shares and files.

adding "wins" was supposed to ping samba PCs via their PC Names instead of their IP numbers 192.168.x.x, etc. I added that line after installing winbind.

You are a genius. I've removed wins from the hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 wins line in /etc/nsswitch.conf, and I can now connect by name.

This bug is now solved for me.

Thanks very much


When I remove WINS from nsswitch.conf, this breaks browsing entirely for me. Ping by name also fails - resolution is incorrect because of OpenDNS.

It seems I can connect and ping by name if I use the "servername.local" instead of "servername", even though I don't define the domain of my computers at all because it seems to be related to other bugs.

Can anyone with an OpenDNS style DNS provider suggest how they set up their system to allow SMB network browsing, connect by name AND ping by name?


Changed in samba:
status: Unknown → New
Steve Langasek (vorlon) wrote :

If you are using opendns, then address resolution will not work correctly because samba gives precedence to DNS records over broadcast name resolution by default. This is considered a reasonable default because broadcast name resolution is not scalable and should be a method of last resort; however, opendns breaks the assumption that DNS servers won't return bogus records when asked for hosts that they have no clue about. This should be considered a bug in opendns, but since they are unlikely to fix that misbehavior any time soon, you can work around this by setting the following value in the [global] section of your /etc/samba/smb.conf:
 name resolve order = lmhosts wins bcast host

Alternatively, you can configure your network to use a wins server instead (though this is probably overkill for a home network).

The other problem mentioned in this bug report is when 'wins' is mentioned in /etc/nsswitch.conf. I think this is a bad idea in general because NetBIOS name resolution semantics are not entirely compatible with traditional 'host' lookups, but since we provide the nss_wins backend we should at least try to fix the bugs in it. And there are bugs in it, which may cause problems particularly when called by something which itself uses samba code (i.e., anything that uses libsmbclient, including nautilus).

As a workaround for this bug, you can again adjust your name resolve order to either 'lmhosts wins bcast host' to use NSS as a last resort, or just 'lmhosts wins bcast' if you know you should never need NSS lookups of hostnames.

Changed in nautilus:
status: New → Confirmed
JimmyKang (james-king) wrote :


thanks for your post. I was hoping there was a way to fix this without disabling windows name resolution.

You say that it is a bad idea in general to use wins resolution. Is there a better way to resolve windows host names especially when using a DHCP server?

Setting /etc/samba/smb.conf to:

  name resolve order = lmhosts wins bcast host

And leaving /etc/nsswitch.conf as default allows me to browse OK.

Thanks for the advice Steve. You said:

"... Opendns breaks the assumption that DNS servers won't return bogus records when asked for hosts that they have no clue about. This should be considered a bug in opendns..."

Unfortunately Charter, Verizon and several other ISPs also set up their DNS the same way - they see it as a revenue generator and have no sympathy for the issues it causes.


Ed Comer (celem) wrote :

Setting /etc/samba/smb.conf to: name resolve order = lmhosts wins bcast host also makes it work for me. It hasn't worked since Dapper - hooray!

FYI - I run Hardy Heron on a laptop with my only connection via WiFi to a wireless router which has a window box connected to it via cable. I am not running SAMBA yet the above change made SMBClient work.

Thanks Steve, That's fixed it for me (Setting /etc/samba/smb.conf to:
  name resolve order = lmhosts wins bcast host).

I had previously thought that adding the value "wins" in the line in /etc/nsswitch.conf as suggested by va9rant had fixed it, and it had, but it also stopped the network drives mounted in /etc/fstab from mounting, as they stopped being able to be resolved (despite being on the same server as the one I was having trouble manualy mounting).

Anyway, thanks Steve


Nikos (nkakouros) wrote :

Hello all,

I'm afraid I'm having the same problem.
I'm trying to connect to the Samba shares on a NAS-4220-B Icybox.

I keep getting Couldn't display "smb:// There is no application installed for this file type" messages.

I now realize this is a misleading message as it has nothing to do with 'no application [being] installed' but rather with an inability to access the shares. Whenever I get this message, if I go back to Places->Network->NICY (nicy is the name of the server) no shares show.

I noticed that connecting to the server in some way (eg opening its webconfig window) makes the shares re-appear... The already mounted shares on the desktop then still do not work BUT if I then unmount and remount them, they work fine !! (for a bit!!)

This sounds similar to jimmyKangs problem -- I'm also using 64bit.

I've changed to
name resolve order = lmhosts wins bcast host
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 wins

Any further ideas would be most welcome.

many thanks,


Hi Nikos,
You're having a different problem to this bug. This bug is about being able to connect by IP address, but not by server name. Your problem seems to be that you can't even connect by IP, which is a different issue.



moschops (simon-waddington) wrote :

I have a Hardy Heron machine that is trying to connect to a share on a Gutsy machine and I get the same problem trying to connect to the share. If I follow the instructions to remove 'wins' from nsswitch on both sides (it was only originally on the Gutsy machine), enable the mdns4 on both sides then I can connect and browse using the ".local" suffix. Thing is I didn't want to have to type that...

This is without any change to the resolve order in smb.conf

To try and enable .local-less resolution and correct connecting and browsing I added wins to the nsswitch.conf line and uncommented the resolve order in smb.conf and set it to have wins at the end. But this did not work (although I could now ping without .local again) and the nautilus error on connecting to a share returned.

I think I'm going to resign myself to having to type .local all the time...

Changed in samba:
assignee: desktop-bugs → nobody
Gabriel Čenkei (gabox) wrote :

Confirming this bug on Jaunty Beta. The first connection is always successfull, the shared folder icon appears on desktop and on nautilus sidebar too. The error message pops up when I retry to connect the shared folder couple of minutes (10-15) after. This happens with retrying to connect via desktop icon only. Connection via icon on nautilus sidebar works always as expected.

The shared folder is on NAS box, which often get into sleep mode. Maybe it is related. I think there could be a bit more timeout for "trying to connect" with some notification or countdown, instead of Error message.
I will try to reproduce the error msg. and share what I'll find out.

Gabriel Čenkei (gabox) wrote :

So I can reproduce the bug. Now I am sure, it has nothing related with NAS box sleep mode. The first connection went good as always. The desktop icon works. After couple of minutes (10-15), I try to reconnect.

1. The first error message appears (pic1 - Sorry for foreign language), it says: "Error: No data available. Choose another browser please and try again."
2. After couple of retries (always via desktop icon), the second error msg. appears. "The file is of an unknown type". After couple of minutes and retries, still no luck to connect via desktop icon.
3. Then I try to connect via nautilus sidebar icon. The connection went fine as expected.

Gabriel Čenkei (gabox) wrote :

Important notice: After reconnect via nautilus sidebar icon, the desktop icon works too.

Thierry Carrez (ttx) wrote :

How is your problem related to this bug ? This bug is about being able to connect by IP address, but never by server name. In your case, you can connect once... then the connection dies somehow. Please open a separate bug to track your issue.

Thank You for response. I was looking for my bug in launchpad, and picked
this thread because of the same error pop-up window. Sorry for confusion, I
try to open a new bug report.

2009/4/8 Thierry Carrez <email address hidden>

> Gabriel:
> How is your problem related to this bug ? This bug is about being able to
> connect by IP address, but never by server name. In your case, you can
> connect once... then the connection dies somehow. Please open a separate bug
> to track your issue.
> --
> Connect to smb server by name doesn't work, but by IP address does
> You received this bug notification because you are a direct subscriber
> of the bug.

Muzer (muzerakascooby) wrote :

I had the same problem in Kubuntu. The problem was is that DNS was set to resolve before WINS, meaning that openDNS jumped in, fooling the app into thinking that was it. The fix was to move "wins" from the end of line 11 in /etc/nsswitch.conf to after "files". Then it worked fine, if a little slowly.

Mastermolch (molchx) wrote :

The problem disappeared with Karmic Koala on my PC.

Thierry Carrez (ttx) wrote :

Setting to Invalid in samba since it always boiled down to OpenDNS doing resolution in a way that require some configuration for samba to work with.

Changed in samba (Ubuntu):
status: Confirmed → Invalid
Changed in samba (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.