The 1803 Update of Windows 10 and Samba

May 15

After the update to Windows 10 Build 1803 machines could not more connect to the Oracle server when the application was started from a network share or a mapped network drive.

These problems were caused by the fact that applications started from a SMB v1 share could not more connect to any network service (file based access was ok).

The server was a Debian Wheezy Linux machine with Samba 3.6. Samba 3.6 is the first Samba version that supports SMB v2 connections, but unfortunately they are disabled by default. To enable them, you must add the following line to the Samba configuration file /etc/samba/smb.conf:

max protocol = SMB2

Restart Samba and your Windows client, and the connection will be SMBv2.
You can check this opening a PowerShell with administrative (elevated) rights and the following command:


Applications that will not work from a SMBv1 share include: email programs, SSH Clients (putty), curl, database clients, and any type of program that opens some network connection.

In the upgrade of another customer server I had a very unusual issue: the server was using a Sernet Samba version, and the upgrade from Debian Squeeze to Debian Wheezy removed this Samba version. A new installation of the Debian version could not find any users anymore.
Strangely, the Sernet Samba version had their user database in /etc/samba, and the Debian Samba version in /var/lib/samba. Stopping Samba and copying over these database files fixed the issue.