5

I've got a Samba 4 share on a CentOS 7.2 server in my LAN that I access from some Windows 10 clients.
The clients use the server IP to access the share and Samba is configured to be a stand-alone server, not a domain member one.

Everything works fine as expected when internet connection is up, but when there's no internet connection the clients need up to 20 minutes before displaying the login credentials window.

It doesn't seem to be a network related problem: the clients can reach the server, ping it as fast as usual, use other protocols such as HTTP or SSH and in general perform every other network activity over the LAN flawlessly.
Also, the fact that it works after a long waiting, suggests me there's some kind of timeout involved in the process.

If disconnect the WAN cable from my local router and try to access the Samba share from the client, it starts to wait for something (green loading progress on address bar slowly moves), but as soon as I plug in the WAN cable again, the client shows the login window.

The Samba logs (debug level 5) don't show anything abnormal, but there seem to be many connecting attempt which are indeed accepted by the server:

[2016/11/15 16:18:34.378116, 3] ../source3/lib/access.c:338(allow_access) Allowed connection from 192.168.100.5 (192.168.100.5) [2016/11/15 16:18:34.436829, 5] ../lib/dbwrap/dbwrap.c:178(dbwrap_check_lock_order) check lock order 2 for /var/lib/samba/serverid.tdb [2016/11/15 16:18:34.436924, 5] ../lib/dbwrap/dbwrap.c:146(dbwrap_lock_order_state_destructor) release lock order 2 for /var/lib/samba/serverid.tdb ... ... this is repeated an unbelievably lot of times ... ...

I'm incline to think it's a Windows 10 related problem more than a network/samba/server one.

Improve this question
12
  • Is either side attempting to perform name resolution on an internet-dependent interface, are are they performing name resolution locally within the network? Also, are they attempting to contact an identity server that is similarly encumbered by public addressing or naming? How is your Samba server storing user identities?
    – Spooler
    Nov 19, 2016 at 12:20
  • No name resolution involved, local ip addresses are used. No identity server or similar service either. Samba users are also system users on the server running samba, it's really a simple plain standalone server. Samba logs show that a connection is indeed happening and the server seems to authorize it, but the client is waiting for something else instead...
    – Eggplant
    Nov 19, 2016 at 13:30
  • Can you do a packet capture on the router during connection?
    – mzhaase
    Nov 21, 2016 at 13:21
  • I can't on the router since it's a very simple netgear model which doesn't offer such capability. I tried Microsoft Message Analyzer on one Windows client, but the logged messages are way too many and I'm currently trying to isolate the significative ones.
    – Eggplant
    Nov 21, 2016 at 15:16
  • OK. Yes, there's a ton of info, but that seems to be your best and easiest path to understanding the delay. You could try grabbing a capture with Wireshark instead.
    – TristanK
    Nov 22, 2016 at 13:06

3 Answers 3

Reset to default
5

I get the exact same situation as yours -- Samba in LAN works well when WAN port is up, but is painfully slow if WAN port is down. I finally figured out why with tcpdump.

Samba tries to resolve its hostname.

My Samba server does not have its own hostname entry in /etc/hosts, so it tries to resolve it on the Internet, this takes a long time if WAN is down.

Add your Samba server's A / PTR record to your LAN nameserver (which is used by Samba), or just add a hostname entry to /etc/hosts on Samba. No more green progress bars!

Improve this answer
1
  • Yep, this is actually the right answer. I had already figured it out myself (using tcpdump too) and it's really counter-intuitive: even if no hostname is used and NetBIOS is disabled in both Samba config file and clients (ie. using only IP addresses), Samba tries to resolve its own hostname. That's most likely so that it is able to expand %m and %h variables in the config file (yes, even if you don't actually use them!). Adding a line to /etc/hosts with the own server's local IP and its hostname fixes the problem. And, as you mentioned as well, speed has improved greatly.
    – Eggplant
    May 13, 2017 at 20:02
1

The fact that you use ip address to mount share doesn't mean there is no name resolution involved.
There is such a thing as reverse name resolution.
This happens when client is trying to figure out FQDN of the server based on it's IP. (think dig -x ipaddress kind of deal)

For a quick test I suggest to add some name to the IP address of a share on a client C:\Windows\system32\drivers\etc\hosts file and see if this helps.
You can find detailed instructions with examples for example here https://support.rackspace.com/how-to/modify-your-hosts-file/

You can also install wireshark on the client and capture network traffic at the time you have a problem. Then filter by port 53 (DNS). You should see if there is any reverse name resolution going on.

Improve this answer
1
  • Thank you for your reply. Unfortunately adding the IP of the server where the samba share is located in the hosts file didn't help. I could ping name-of-the-server so it means the entry was being processed (I even rebooted the client), but the problem with Samba remained the same. I'm going to try wireshark as soon as possible and provide some feedback here.
    – Eggplant
    Nov 24, 2016 at 17:19
0

It seems a DNS-related problem: the client or the server are tring to resolve (or reverse-resolve) the other machine, and this lead to timeout/slow connection. As many router supports DNS forwarding, try the following:

  • set, on your router, Google's DNS (8.8.8.8 and 8.8.4.4)
  • on both client and server, set your router's internal IP address as both gateway and DNS
  • disconnect the WAN cable and re-try connection

Does that change anything?

Improve this answer
1
  • I have already tried all of those, no luck. I don't think it's a DNS-related problem, as I wrote before, the network is working fine and also other protocols (http, ssh, etc.) are working as expected between the clients and the server.
    – Eggplant
    Nov 25, 2016 at 8:29

You must log in to answer this question.

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