Bug 12558 - Server not accessable if max protocol = NT1
Summary: Server not accessable if max protocol = NT1
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.5.5
Hardware: All Solaris
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-03 15:48 UTC by Tom Schulz
Modified: 2017-04-21 06:50 UTC (History)
2 users (show)

See Also:


Attachments
Attempt to access share with samba 4.5.6 (448.34 KB, text/plain)
2017-03-14 17:46 UTC, Tom Schulz
no flags Details
Sucessful access with Samba 4.4.8 (1.06 MB, text/plain)
2017-03-14 17:50 UTC, Tom Schulz
no flags Details
Packet capture using tcpdump of a failing connection (2.57 KB, application/vnd.tcpdump.pcap)
2017-03-15 18:44 UTC, Tom Schulz
no flags Details
Packet capture using tcpdump of a sucessful connection (4.05 KB, application/vnd.tcpdump.pcap)
2017-03-15 18:49 UTC, Tom Schulz
no flags Details
Tcpdump of working connection Samba 4.4 (34.33 KB, application/octet-stream)
2017-04-05 14:25 UTC, Tom Schulz
no flags Details
Tcpdump of failing connection Samba 4.5 (6.72 KB, application/octet-stream)
2017-04-05 14:28 UTC, Tom Schulz
no flags Details
The smb.conf file (1.89 KB, text/plain)
2017-04-06 14:42 UTC, Tom Schulz
no flags Details
Tcpdump of working connection Samba 4.4 try again (50.01 KB, application/octet-stream)
2017-04-06 15:49 UTC, Tom Schulz
no flags Details
Tcpdump of failing connection Samba 4.5 try again (23.49 KB, application/octet-stream)
2017-04-06 15:53 UTC, Tom Schulz
no flags Details
Patch (1.33 KB, patch)
2017-04-06 20:18 UTC, Volker Lendecke
no flags Details
git-am fix for 4.6.next, 4.5.next. (2.65 KB, patch)
2017-04-10 22:40 UTC, Jeremy Allison
vl: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Schulz 2017-02-03 15:48:13 UTC
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.
Comment 1 Tom Schulz 2017-02-17 17:09:45 UTC
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.
Comment 2 Tom Schulz 2017-03-10 16:38:59 UTC
ping
Comment 3 Stefan Metzmacher 2017-03-10 16:41:22 UTC
(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.
Comment 4 Tom Schulz 2017-03-10 16:56:41 UTC
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.
Comment 5 Stefan Metzmacher 2017-03-10 23:14:12 UTC
(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)
Comment 6 Tom Schulz 2017-03-11 02:30:54 UTC
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.
Comment 7 Tom Schulz 2017-03-14 17:46:25 UTC
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.
Comment 8 Tom Schulz 2017-03-14 17:50:07 UTC
Created attachment 13057 [details]
Sucessful access with Samba 4.4.8

hopefully the correct debug level 10 of a sucessful connection.
Comment 9 Tom Schulz 2017-03-15 18:44:53 UTC
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.
Comment 10 Tom Schulz 2017-03-15 18:49:12 UTC
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.
Comment 11 Tom Schulz 2017-03-17 17:03:43 UTC
Have I provided everything that you need?
Comment 12 Tom Schulz 2017-03-24 13:42:53 UTC
Ping.
Comment 13 Tom Schulz 2017-03-28 14:34:48 UTC
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.
Comment 14 Tom Schulz 2017-04-04 15:47:47 UTC
Ping.
Comment 15 Volker Lendecke 2017-04-04 18:22:37 UTC
The network traces only show the client->server packets, not the replies. Can you check your snoop options?
Comment 16 Tom Schulz 2017-04-05 14:25:23 UTC
Created attachment 13133 [details]
Tcpdump of working connection Samba 4.4

Try again. Tcpdump of a working connection using Samba 4.4.
Comment 17 Tom Schulz 2017-04-05 14:28:01 UTC
Created attachment 13134 [details]
Tcpdump of failing connection Samba 4.5

Try again. Tcpdump of a failing connection using Samba 4.5
Comment 18 Volker Lendecke 2017-04-06 14:00:33 UTC
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.
Comment 19 Tom Schulz 2017-04-06 14:42:11 UTC
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.
Comment 20 Volker Lendecke 2017-04-06 14:47:34 UTC
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?
Comment 21 Volker Lendecke 2017-04-06 14:49:08 UTC
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!
Comment 22 Tom Schulz 2017-04-06 15:26:12 UTC
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.
Comment 23 Tom Schulz 2017-04-06 15:49:40 UTC
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.
Comment 24 Tom Schulz 2017-04-06 15:53:45 UTC
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.
Comment 25 Volker Lendecke 2017-04-06 20:18:05 UTC
Created attachment 13140 [details]
Patch

Can you try the attached patch? Thanks!
Comment 26 Tom Schulz 2017-04-07 14:07:26 UTC
That fixes it!
Comment 27 Tom Schulz 2017-04-07 14:26:47 UTC
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.
Comment 28 Volker Lendecke 2017-04-07 14:44:10 UTC
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.
Comment 29 Jeremy Allison 2017-04-07 23:20:28 UTC
(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 :-(.
Comment 30 Jeremy Allison 2017-04-10 22:40:29 UTC
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.
Comment 31 Jeremy Allison 2017-04-11 16:05:01 UTC
Re-assigning to Karolin for inclusion in 4.6.next, 4.5.next.
Comment 32 Karolin Seeger 2017-04-19 07:36:56 UTC
(In reply to Jeremy Allison from comment #31)
Pushed to autobuild-v4-{5,6}-test.
Comment 33 Karolin Seeger 2017-04-21 06:50:58 UTC
(In reply to Karolin Seeger from comment #32)
Pushed to both branches.
Closing out bug report.

Thanks!