Bug 13384 - macOS High Sierra 10.13.4 cannot connect
Summary: macOS High Sierra 10.13.4 cannot connect
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.8.0
Hardware: x86 Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
Depends on:
Reported: 2018-04-12 20:34 UTC by andreas
Modified: 2018-04-24 07:42 UTC (History)
2 users (show)

See Also:

logfile with error (2.14 KB, text/plain)
2018-04-12 20:34 UTC, andreas
no flags Details
packet-capture of login-attempt (849 bytes, application/octet-stream)
2018-04-13 19:28 UTC, andreas
no flags Details
complete logfile of login-attempt (48.14 KB, text/plain)
2018-04-13 19:30 UTC, andreas
no flags Details
packet-capture of login-attempt to Win10 (14.17 KB, application/octet-stream)
2018-04-14 10:53 UTC, andreas
no flags Details
packet-dump from server-side (1.06 KB, application/octet-stream)
2018-04-16 10:12 UTC, andreas
no flags Details
used smb.conf (1.08 KB, text/plain)
2018-04-16 10:12 UTC, andreas
no flags Details
log.smbd level 10 (48.14 KB, text/plain)
2018-04-16 10:12 UTC, andreas
no flags Details
strace.output of running smbd-processes including childs (407.49 KB, text/plain)
2018-04-16 10:13 UTC, andreas
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description andreas 2018-04-12 20:34:17 UTC
Created attachment 14132 [details]
logfile with error

Compiled Samba 4.8.0 and running successfully on CentOS/OracleLinux/RedHat 7.5 Beta (x86_64).

When trying to connect from Windows 10, the connection works. SMBClient 4.8 from the same OracleLinux 7.5-host with smbclient 4.8 also works fine. But when trying to connect from macOS High Sierra 10.13.4 the connection failes with the following error in the samba logfile with log level = 10:


See for details the attached logfile.
Comment 1 Volker Lendecke 2018-04-13 09:35:57 UTC
Can you upload a network trace? Info on how to do that can be found under https://wiki.samba.org/index.php/Capture_Packets
Comment 2 andreas 2018-04-13 19:27:53 UTC
I did a packet capture of the error as you asked. I also included a complete log of the  login attempt.
Comment 3 andreas 2018-04-13 19:28:49 UTC
Created attachment 14134 [details]
packet-capture of login-attempt
Comment 4 andreas 2018-04-13 19:30:14 UTC
Created attachment 14135 [details]
complete logfile of login-attempt
Comment 5 Volker Lendecke 2018-04-14 06:26:48 UTC
They send an echo request right after the smb1 negprot. This looks broken....

If possible -- can you do the same network trace when connecting against modern Windows (modern in terms of Windows7+?). It seems that tcpdump is available on macos too: https://support.apple.com/en-us/HT202013.

Thanks a lot!
Comment 6 andreas 2018-04-14 10:52:08 UTC
I did a network trace to a Windows 10 ver 1709. I even logged in.

The tcpdump was of port 445/tcp, 139/tcp, 137/udp and 138/udp to be sure.
Comment 7 andreas 2018-04-14 10:53:02 UTC
Created attachment 14136 [details]
packet-capture of login-attempt to Win10
Comment 8 Stefan Metzmacher 2018-04-16 08:27:27 UTC
Samba needs 15 seconds to answer the negotiate request and the client sends
the echo after 10 seconds...

In the log file we have this:

[2018/04/13 21:24:28.726920,  5, pid=2361, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:425(load_auth_module)
  load_auth_module: auth method sam_ignoredomain has a valid init
[2018/04/13 21:24:43.766541,  3, pid=2361, effective(0, 0), real(0, 0), class=auth] ../auth/gensec/gensec_start.c:977(gensec_register)
  GENSEC backend 'gssapi_spnego' registered

I think we need the output of strace -f -ttT -o /tmp/strace.output smbd ...,
(together with a network capture and a level 10 log file) in order to find what happened in those 15 seconds between these messages.
Comment 9 andreas 2018-04-16 10:11:30 UTC
Attached the tracefiles with network-trace (from server side) and log.smbd. And for completeness my smb.conf as well.
Comment 10 andreas 2018-04-16 10:12:03 UTC
Created attachment 14137 [details]
packet-dump from server-side
Comment 11 andreas 2018-04-16 10:12:17 UTC
Created attachment 14138 [details]
used smb.conf
Comment 12 andreas 2018-04-16 10:12:37 UTC
Created attachment 14139 [details]
log.smbd level 10
Comment 13 andreas 2018-04-16 10:13:17 UTC
Created attachment 14140 [details]
strace.output of running smbd-processes including childs
Comment 14 Stefan Metzmacher 2018-04-17 06:33:19 UTC
(In reply to andreas from comment #13)

There seems to be a problem with dns.

What do you have in /etc/nsswitch.conf, /etc/hosts and /etc/hostname.

I guess the local hostname is not resolvable.
Comment 15 andreas 2018-04-17 08:22:21 UTC
Completely correct! I didn't enter my hostname with IP into the hosts-file as this is a DHCP-host, also no DNS-entry (because of DHCP). I entered my local hostname into the /etc/hosts and I can connect to the SMB-server now. 

Strange behaviour however that the response takes too long if the ip/hostname cannot be resolved. Also because the host is being announced by avahi and the TimeMachine-stuff. Is this behaviour the same in lower versions of SMB?

The expected behaviour (from my side) is that the SMB-server is being announced by avahi and usable for TimeMachine purposes, without DNS-resolving-issues. I can imagine that not every host has a static hosts-entry or has a resolvable ip/hostname.
Comment 16 andreas 2018-04-24 07:42:06 UTC
Adding my own name to the hosts-file fixed the connection issue. For me this is a usable workaround but I can imagine that for some systems with DHCP this isn't such a good solution, as Samba broadcasts itself with mDNS/Avahi.