Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I added a Debian etch host (hostname: webserver, IP address: running Samba to a Windows network with a Windows 2003 PDC (IP address The Samba server exports a public guest share, called "Intranet". The server shows up fine in the network, but trying to click on it produces an error dialog, stating I don't have the necessary permissions. So does entering \webserver manually and using \webserver\internet states that the path does not exist. Interestingly, accessing the share by IP address (\ or \\intranet) works fine. DNS is configured correctly, and "smbclient //webserver/intranet" on another Linux client works fine.

One complicating issue is that the webserver is only a VMware virtual machine running on PDC server.

Here is our smb.conf:

    workgroup = Foobar
    server string = Webserver
    wins support = yes                 ; commenting out these
    wins server = ; two lines has no effect
    dns proxy = no
    guest account = nobody
    [... snipped some unrelated bits, like logging ...]
    security = share
    [... snipped some password-related things ...]
    domain master = no

    comment = Intranet
    path = /srv/webserver/contents
    browseable = yes
    guest ok = yes
    guest only = yes
    read only = yes
    create mask = 0775
    directory mask = 0775
share|improve this question
Does the FQDN work? i.e. \\\intranet? – Chris Brentano Oct 14 '09 at 21:22
No, using the FQDN has the same problems. – Sebastian Rittau Oct 15 '09 at 16:29
Is nslookup is working? Recent versions of Windows started to prefer DNS over WINS. – Mircea Vutcovici Mar 20 '10 at 0:18

If your client can access the share using \\<IP-ADDRESS>\<SHARE-NAME>, then this definitely points at name resolution.

I would therefore double-check the DNS side of things, as \\<FQDN>\<SHARE-NAME> is effectively the same as above. If you don't provide an FQDN, and only provide a host name and the [Windows] client is still supporting legacy NBT, it will try WINS name resolution as well.

Finally, if the Windows Client is running on Windows 7 or Windows Server 2008 R2 (not sure about Vista / Server 2008 R1), the client by default wants to use NTLMv2. Older SAMBA distributions only support LAN Manager and NTLMv1, which makes it impossible to connect. However, you've managed to connect, so this is probably irrelevant. You can change the client's modus operandi by means of Local Security Policy or GPO.

Long story short, make sure your SAMBA distro is up to date. And I'd seriously consider dropping the NBT side of your SMB.CONF file (WINS entries).

Good luck!

share|improve this answer

My first guess would be firewall. You need to have ports 137, 138, 139 open for both tcp and udp for Windows to play nice with a Linux Samba server.

share|improve this answer
The Firewall is turned off. All ports are reachable, except 137 and 138 per TCP (which seems to make sense, though). – Sebastian Rittau Oct 15 '09 at 16:30
Not true. Newer versions of SAMBA play nicely with pure SMB (TCP 445), and don't need legacy NBT (TCP 137). – Simon Catlin Oct 7 '13 at 20:44
@SimonCatlin Probably depends on the versionof Samba being used, and certainly the need for the netbios ports is less necessary in 2013 with SMB2, but in 2009 needing those ports open was pretty common practice. – Ophidian Oct 8 '13 at 13:44
Indeed, I should have put "not necessarily true" (!). – Simon Catlin Oct 8 '13 at 17:50

Are you sure that both the smbd and nmbd processes are running on the server?


ps aux | grep mbd
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.