Samba access works with IP address only

Question

I added a Debian etch host (hostname: webserver, IP address: 192.168.101.2) running Samba to a Windows network with a Windows 2003 PDC (IP address 192.168.101.3). 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 (\192.168.101.2 or \192.168.101.2\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:

[global]
    workgroup = Foobar
    server string = Webserver
    wins support = yes                 ; commenting out these
    wins server = 192.168.101.3 ; 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

[intranet]
    comment = Intranet
    path = /srv/webserver/contents
    browseable = yes
    guest ok = yes
    guest only = yes
    read only = yes
    create mask = 0775
    directory mask = 0775

Does the FQDN work? i.e. \\webserver.yourdomain.com\intranet? — Chris Brentano, Oct 14 '09 at 21:22
Is `nslookup webserver.yourdomain.com` is working? Recent versions of Windows started to prefer DNS over WINS. — Mircea Vutcovici, Mar 20 '10 at 00:18

score 1 · Answer 1 · answered Oct 07 '13 at 20:52

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!

score -1 · Answer 2 · answered Nov 15 '11 at 23:07

-1

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

Try:

ps aux | grep mbd

answered Nov 15 '11 at 23:07

Hubert Kario

6,361
6
36
65

score -1 · Answer 3 · answered Oct 14 '09 at 16:02

-1

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.

answered Oct 14 '09 at 16:02

Ophidian

2,178
14
14

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 07 '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 08 '13 at 13:44
Indeed, I should have put "not necessarily true" (!). – Simon Catlin Oct 08 '13 at 17:50

Samba access works with IP address only

3 Answers3