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.

  • 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 '16 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 '16 at 13:30
  • Can you do a packet capture on the router during connection? – mzhaase Nov 21 '16 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 '16 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 '16 at 13:06
4

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!

  • 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 '17 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.

  • 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 '16 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?

  • 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 '16 at 8:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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