The core issue stems from Windows 10's default SMB protocol behavior differing significantly from Windows 7. When examining the Samba logs, we see Windows 10 attempting multiple protocol versions before settling on SMB3_00, while Windows 7 directly uses SMB2_10.

# Sample from Windows 10 log
switch message SMBnegprot (pid 2855) conn 0x0
protocol negotiation: SMB2_FF -> SMB 2.??? -> SMB3_00
Server exit (NT_STATUS_END_OF_FILE)

For Ubuntu 14.04 with Samba 4.1.11, these settings force compatible protocol versions:

[global]
   workgroup = WORKGROUP
   server min protocol = SMB2_02
   server max protocol = SMB3
   security = user
   encrypt passwords = yes
   min receivefile size = 16384
   socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536

Execute these PowerShell commands to enable legacy SMB protocols:

# Enable SMB1 (not recommended for security reasons)
Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

# Force SMB2 as minimum version
Set-SmbClientConfiguration -RequireSecuritySignature $true -EnableSecuritySignature $true -Confirm:$false

When servers and clients aren't on the same LAN:

• Ensure TCP ports 445, 139 are forwarded correctly
• Verify MTU settings aren't causing packet fragmentation
• Check firewall rules on both Windows and Ubuntu

Use these commands to verify Samba configuration:

# Test configuration file
testparm -s

# Debug authentication
smbclient -L //127.0.0.1 -U%

# Packet capture for protocol analysis
tcpdump -i eth0 port 445 -w smb.pcap

If protocol negotiation continues to fail:

1. Mount using IP address instead of hostname
2. Try using net use command with specific options:

net use Z: \\server\share /user:username * /persistent:yes

When attempting to connect from Windows 10 to a Samba 4.1.11 server running on Ubuntu 14.04, the protocol negotiation fails with NT_STATUS_END_OF_FILE while Windows 7 clients connect successfully. The key difference lies in the SMB protocol version negotiation:

# Windows 10 negotiation sequence
SMBnegprot → SMB2_FF → SMB 2.??? → SMB3_00 → NT_STATUS_END_OF_FILE
# Windows 7 successful sequence
SMB2_10 → successful connection

Windows 10 defaults to newer SMB protocols (v2/v3) for security reasons, while older Samba versions may not properly support these protocols. The log shows Windows 10 attempts these negotiation steps:

1. Initial protocol switch message (SMBnegprot)
2. Requesting multiple protocols before selecting SMB2_FF
3. Security negotiation failures
4. Final termination with NT_STATUS_END_OF_FILE

Add these parameters to your smb.conf:

[global]
   # Protocol version enforcement
   client min protocol = SMB2
   client max protocol = SMB3
   server min protocol = SMB2
   server max protocol = SMB3

   # Security settings
   ntlm auth = yes
   lanman auth = no
   client ntlmv2 auth = yes

For Windows clients that must connect to older servers, create a .reg file with these contents:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"AllowInsecureGuestAuth"=dword:00000001
"ClientNtlmv2AuthEnabled"=dword:00000001
"RequireSecuritySignature"=dword:00000000
"EnableSecuritySignature"=dword:00000000

Ensure these ports are open when connecting across networks:

• TCP 445 (SMB over TCP)
• TCP 139 (NetBIOS session service)
• UDP 137-138 (NetBIOS name service)

For Ubuntu firewall:

sudo ufw allow 445/tcp
sudo ufw allow 139/tcp
sudo ufw allow 137:138/udp

If protocol negotiation continues to fail, map the drive using explicit credentials:

net use Z: \\server\share /user:username password /persistent:yes

Or via PowerShell:

New-PSDrive -Name "Z" -PSProvider "FileSystem" -Root "\\server\share" -Persist -Credential (Get-Credential)