1

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
3
  • Does the FQDN work? i.e. \\webserver.yourdomain.com\intranet? Commented Oct 14, 2009 at 21:22
  • No, using the FQDN has the same problems. Commented Oct 15, 2009 at 16:29
  • 2
    Is nslookup webserver.yourdomain.com is working? Recent versions of Windows started to prefer DNS over WINS. Commented Mar 20, 2010 at 0:18

3 Answers 3

1

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!

-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.

4
  • The Firewall is turned off. All ports are reachable, except 137 and 138 per TCP (which seems to make sense, though). Commented Oct 15, 2009 at 16:30
  • Not true. Newer versions of SAMBA play nicely with pure SMB (TCP 445), and don't need legacy NBT (TCP 137). Commented Oct 7, 2013 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
    Commented Oct 8, 2013 at 13:44
  • Indeed, I should have put "not necessarily true" (!). Commented Oct 8, 2013 at 17:50
-1

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

Try:

ps aux | grep mbd

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .