Fixing Broken Samba File Share Access for Linux Hosts with Windows 10
If the newest installation of the Windows 10 is leaving you with some file sharing issues, check out this developer's solution.
Join the DZone community and get the full member experience.Join For Free
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, mine is 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 locationfailed 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 the 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.
Published at DZone with permission of Douglas Rathbone, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.