For the past few weeks I’ve been battling to get my Linux instances to access file shares on my Windows 10 instances over the network. Whether it was Ubuntu, Fedora, or RedHat, the recent upgrades to Windows 10 left my Windows shares inaccessible via Samba. Troubleshooting was difficult as I had nothing to go on exception really ambiguous messages via the syslog (“Failed to mount Windows share: Connection timed out”). After some trial and error it all came down to an undocumented change in how Windows 10 supports the SMB protocol.

Like most horrible troubleshooting stories, my one was filled with dead ends and false (and self inflicted) root causes.

I run a number of Linux based hosts on my home network, and after installing the latest version of Windows 10 Insider Edition, accessing network file shares on Windows 10 hosts from from Ubuntu simply stopped working. I immediately assumed that the Insider Edition had broken network sharing support, as among other things Home Groups were gone (I later discovered this was sadly by design from Creators Update onwards – and I was running the Insider version of Spring Creators Updates).

After configuring a non-Insiders Edition Windows desktop to run file sharing, I realized that this was also broken – This issue must have existed for a few months before i’d noticed it.

Then I turned to my primary Ubuntu file server.

This is the ambiguous error I was seeing in the Ubuntu Network Manager:

Unable to access location
Failed to mount Windows share: Connection timed out

Digging a little deeper the syslog showed a similar message with little additional context:

dbus_mount_reply: Error from org.gtk.vfs.Mountable.mount(): Failed to mount Windows share: Connection timed out

Assuming this was a samba file sharing issue I set about attempting to troubleshoot the networking issue by running smbclient and smbtree varying levels of logging turned on (eg “smbtree –d4”) to see if there was anything going wrong in the handshake process to my Windows 10 machines.

Frustratingly I saw similar timeout errors while attempting to troubleshoot.

The Solution (and a guess at Root Cause)

After rummaging around in both the Samba and Windows 10 release notes for the past few version I noticed that Windows 10 now offers you install a Windows feature to enable Samba 1 shares. This indicates that SMB 1 isn’t supported by default:

With this little fact to go on, I had the idea that Windows 10 may be blocking Samba clients from negotiating at lower levels of the SMB protocol. SMB 3.1.1 was released with Windows 10 and Windows Server 2016, adding improved encryption. Assuming the latest version of Windows 10 has started enforcing use of higher versions of SMB this sounded like a possible cause.

While this might make sense, Samba is meant to support SMB 3 (man pages), so running the latest version of Samba assumes this isn’t a problem.

Well you’d assume incorrectly.

Reconfiguring Samba to use a minimum protocol version of SMB 3, all of my issues were magically resolved.

To do this, edit your /etc/samba/smb.conf and under the [global] section of your Samba config define the minimum version of the SMB protocol to use SMB 3.

[global]
client min protocol = SMB3

Alternatively, this can also be done with the following one-liner:

$ sudo sed -i "/\\[global\\]/a client min protocol = SMB3" /etc/samba/smb.conf

Once these settings are saved, Windows 10 shares should be accessible from your Ubuntu/Fedora/Redhat instance and you’re off and racing again.