With Samba 4.5.5 Windows reports that the server is not accessable if max protocol = NT1 is specified. I have not tested earlier versions of 4.5.* for this problem. There is no problem with 4.4.9. I have been running the 4.5.* series on a different server that does not specify max protocol = NT1 with no problems. We seem to need max protocol = NT1 to get things to work through our vertual private network.
After the switch to Samba 4.5.5 with max protocol = NT1 set in the smb.conf file, the error message when I browse to the server and try to click on a share is: \\SERVER\schulz is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. The filename, directory name, or volume label syntax is incorrect. For an already mapped drive, the error message is: Y:\ is not accessible. The filename, directory name, or volume label syntax is incorrect.
ping
(In reply to Tom Schulz from comment #2) Did you reboot the client after the change? Windows clients typically cache if the server supports SMB2 or higher and start with an SMB2 negprot for reconnects.
Yes, I rebooted the client. To be clear, I first found the problem when I tried to upgrade from 4.4.9 to 4.5.5 on a server which already had 'max protocol = NT1' specified. I then swithed to testing on a less used server that did not originally have that set and was already running 4.5.5. I rebooted the client after each change.
(In reply to Tom Schulz from comment #4) Can you upload a capture including a level 10 log, https://wiki.samba.org/index.php/Capture_Packets and https://wiki.samba.org/index.php/Client_specific_logging. I need this for the working case (with 4.4) and the failing case (with 4.5 and/or 4.6)
I will try to do that. But I wonder if you could reproduce the problem there. I don't think there is anything special about the way I built Samba.
Created attachment 13056 [details] Attempt to access share with samba 4.5.6 This is hopefully a good debug level 10 of a failing connection with Samba 4.5.6 runing with max protocol NT1.This is the file named after the client trying to access the share. I am assuming that the log.smbd file is not anything that you need. Let me know if this is not what you wanted.
Created attachment 13057 [details] Sucessful access with Samba 4.4.8 hopefully the correct debug level 10 of a sucessful connection.
Created attachment 13065 [details] Packet capture using tcpdump of a failing connection Here is a packet capture using tcpdump of a failing attempt to access a share with samba 4.5.6.
Created attachment 13066 [details] Packet capture using tcpdump of a sucessful connection Here is a packet capture using tcpdump of sucessfuly accessing a share using Samba 4.4.8.
Have I provided everything that you need?
Ping.
I have something of a deadline here. I am going to be retiring in a little under 3 weeks. So if you need any more information or need to have any testing done,it should happen soon. I would like to leave my company running the latest version of Samba when I leave.
The network traces only show the client->server packets, not the replies. Can you check your snoop options?
Created attachment 13133 [details] Tcpdump of working connection Samba 4.4 Try again. Tcpdump of a working connection using Samba 4.4.
Created attachment 13134 [details] Tcpdump of failing connection Samba 4.5 Try again. Tcpdump of a failing connection using Samba 4.5
We're returning OBJECT_NAME_INVALID on a seemingly okay pattern. Tried with a standard 4.5 setup, could not reproduce. Can you please upload your smb.conf together with a full debug level 10 log of smbd running into this issue? Please see https://wiki.samba.org/index.php/Client_specific_Log for information how to get logs.
Created attachment 13137 [details] The smb.conf file Here is the smb.conf file and the first part of the file it includes. We have a lot of shares but the problem happens on all of them. So I only included the first 5 or so. Note that we have a Windows 2000 domain controller. The first attachment I attached to this bug should be the debug level 10 that you need.
Hmm. Ok. This is dfs-related. The server says that it wants DFS-aware pathnames, but the client does not send them. A DFS-Pathname has pathnames of the form \\hostname\dir1\dir2\* . I have no idea why the client does not send that. What kind of client is this? Maybe it is a Windows 95 without DFS extensions?
By the way, the network traces only show the last few packets. To fully diagnose the issue, we need the full TCP connection starting with the initial SYN packet. Can you upload them for both 4.4 and 4.5 again, this time WITH the connection setup up to the failure? Thanks!
I will redo the traces. The client is a Windows 7 computer. The drive is a mapped network drive of my home directory. So it should be using the [homes] share and mapped as \\mackerel\schulz.
Created attachment 13138 [details] Tcpdump of working connection Samba 4.4 try again Tcpdump of working connection using Samba 4.4. This time I shut down the client, restarted the Samba server, booted the client and then accessed the share.
Created attachment 13139 [details] Tcpdump of failing connection Samba 4.5 try again Here is a trace of a failing connection. As in the last one the server was restarted, the trace was started and then the client was booted.
Created attachment 13140 [details] Patch Can you try the attached patch? Thanks!
That fixes it!
That patch also fixes a problem one of our Windows XP machine was having even when max protocol NT1 was not specified. I just noticed that problem late yesterday. I would probably have mentioned it in this bug if I had noticed it earlier.
Thanks for the confirmation. Running a private autobuild with a regression test right now. I'll present the patch to the community once that's done.
(In reply to Volker Lendecke from comment #28) Arg. Sorry Volker, your patch was obviously correct so I already put it in autobuild without reading that last entry. Sorry :-(.
Created attachment 13149 [details] git-am fix for 4.6.next, 4.5.next. Cherry-picked from master - applies cleanly to 4.6.next, 4.5.next.
Re-assigning to Karolin for inclusion in 4.6.next, 4.5.next.
(In reply to Jeremy Allison from comment #31) Pushed to autobuild-v4-{5,6}-test.
(In reply to Karolin Seeger from comment #32) Pushed to both branches. Closing out bug report. Thanks!