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: NT_STATUS_MORE_PROCESSING_REQUIRED NT_STATUS_INVALID_PARAMETER See for details the attached logfile.
Can you upload a network trace? Info on how to do that can be found under https://wiki.samba.org/index.php/Capture_Packets
I did a packet capture of the error as you asked. I also included a complete log of the login attempt.
Created attachment 14134 [details] packet-capture of login-attempt
Created attachment 14135 [details] complete logfile of login-attempt
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!
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.
Created attachment 14136 [details] packet-capture of login-attempt to Win10
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.
Attached the tracefiles with network-trace (from server side) and log.smbd. And for completeness my smb.conf as well.
Created attachment 14137 [details] packet-dump from server-side
Created attachment 14138 [details] used smb.conf
Created attachment 14139 [details] log.smbd level 10
Created attachment 14140 [details] strace.output of running smbd-processes including childs
(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.
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.
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.