-1

Our setup:
Server: Windows Server 2008
Client: SHMZ 6.6 (FreePBX, CentOS)
mount.cifs version: 4.8.1
smbclient version: Version 3.6.23-14.el6_6

Using this command to connect:

mount.cifs //192.168.0.10/Share /mnt/share -o "username=windowsuser,sec=ntlm,servern=SERVERNAME,password=windowsuserpassword"

Takes 1 minute and 3 seconds to mount an empty folder.

Question is: how to speed up the mount process?

UPDATE 1: You may have noticed that I didn't do any diagnosis prior to writing this post. Mainly it's because I don't know where to start. Please give me a at least a hint how to analyze the connection process.

UPDATE 2: Well, I captured the mount process, I see there 2 major lags: ~10 and ~30 seconds. Can't figure out the reason though. Can you please suggest anything? http://tinypic.com/r/2cxz21z/9

real_sm
  • 112
  • 2
  • 14
  • Can somebody please explain why does this question keeps being downvoted? What did I write wrong? I will fix that immediately. Thanks. – real_sm Dec 31 '17 at 15:05
  • Probably getting votes for, "doesn't show previous attempts to diagnose this problem." – sysadmin1138 Dec 31 '17 at 15:08
  • @sysadmin1138 thank you! But I don't know where to start the diagnosis... Anyway, will add this info to the post. – real_sm Dec 31 '17 at 15:09

1 Answers1

2

This is the kind of problem where packet-tracing can be rather helpful.

tcpdump -s 0 -i eth0 -w mount-trace.pcap

Then perform your mount. Cancel the tcpdump once it is done. Then get the mount-trace.pcap file somewhere you can load into wireshark.

It will take some poking about, but mounting windows volumes that take a long time to finish is usually due to both sides of the conversation having trouble agreeing to a protocol to continue the conversation. If you take a look at the man-page for mount.cifs and look at the options for the sec= parameter you're using, you can see how many of them there are.

What you're looking for in wireshark are long gaps between parts of the conversation. That kind of thing can be an indicator of a timeout having to be expired before moving on to a failback method. CIFS is very well supported by Wireshark, and you can learn a lot about how Windows authentication works just by watching the various phases it goes through.

If that's too scary, I suggest removing the sec=ntlm parameter from your mount-command and rely on the default, or setting it to ntlmssp. This has to do with NTLM being an old dialect of the Microsoft authentication protocol, replaced later by NTLMv2 and ultimately . Windows Server 2008 is coming on a decade old and sits in that inbetween space between when NTLM was firmly removed and was still allowed due to legacy reasons.

Unfortunately for everyone, legacy reasons includes really old CentOS versions. Like, Version 5 old.

Once you get it fast again, redo that tcpdump and compare with the first one. You'll see the differences!

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
  • Many thanks! Will get to work! P.S. Without `sec=ntlm` mount.cifs just hanged until reboot. – real_sm Dec 31 '17 at 15:39
  • Well, I captured the mount process, I see there 2 major lags: ~10 and ~30 seconds. Can't figure out the reason though. Can you please suggest anything? http://tinypic.com/r/2cxz21z/9 – real_sm Jan 03 '18 at 22:18
  • @real_sm Packets 19 through 25 are your diagnostic ones. Those show repeated attempts to talk to what looks to be a windows server over TCP/445. This fails. It then falls back to TCP/139, an old port for windows, which works. At this point I'd look at any firewalls between the Windows server and yours and make sure that TCP/445 is opened. I'm not sure how to force mount.cifs to use TCP/139, which is your other option. – sysadmin1138 Jan 05 '18 at 01:19
  • Yes, mount.cifs does allow to use a specific port! Thank you, thank you! How do I mark your comment as a right answer? Or do I mark your answer above as the right answer? – real_sm Jan 05 '18 at 11:36
  • @real_sm Just mark the answer, the comments will show! – sysadmin1138 Jan 05 '18 at 14:42