1

I just upgraded to Windows 10 and so far many things are smooth, however everything related to networks is bonkers (other issues I have: no longer get Internet access through wired connections at work, unable to set priority of wireless networks, random phones appearing in Network, slow DNS hostname resolution, and VirtualBox is still trying to figure out how to get their network drivers working). However, the most frustrating at the moment is the following.

The backup server for all the files is a Samba server called "BACKUP". It is in the same workgroup ("WORKGROUP") as the computer is. At first I couldn't connect to it at all, but after some tweaking of the Samba server settings (making it run a WINS server and be the Domain Master) it now at least works sometimes.

The computer also shows up on the network (always did, even before I changed settings). If I use the IP address (e.g. \192.168.10.150), everything works find now. However, if I use the server name (e.g. \BACKUP) I can only visit one folder about every 3-5 minutes though. Usually attempts take a really long time and end up at "Network path not found". But every so often they go through quickly.

Most things I have found out there do not have this periodic behavior, either they connect or don't. What could be causing these issues?

I have also tried assigning the network share a drive letter without any help (while using the name) and using various commands: net view BACKUP vs net view 192.168.10.150 have the same behavior as with the GUI, net view by itself always lists BACKUP and nbtstat -a BACKUP and nbtstat -a 192.168.10.150 always return the same lists (consisting of various BACKUP and WORKGROUP entries along with a ☺☻__MSBROWSE__☻). The nbtstat -n only lists the WORKGROUP and the local machine. Using nbtstat -S I can see the connection on the list and see that the IP address is properly resolved.

Some things I have noticed, but I am unsure about:

  • nbtstat -a ... both show the BACKUP machine has a MAC address of 00-00-00-00-00-00 which doesn't seem right, however arp -a reports the right value.
  • ping BACKUP resolves to the WAN IP address (the Samba server is not accessible via WAN, but other parts of the BACKUP server are)

The server was working perfectly fine in Windows 7.

So, how do I get the Windows 10 machine to connect to the Samba server by name consistently?

Improve this question

1 Answer 1

Reset to default
3

I've gotten mine working based upon some information I found about a Windows 10 client versus Windows 7 as described in this link.

The Windows 10 client will try to negotiate SMB 3.1.1, which isn't supported yet in Samba (unless you download, build, and install the latest stable source, which I think is Samba 4.3 or later).

The alternative to rebuilding Samba is to issue the commands shown in the follow-up link to force Windows 10 to use the earlier version of SMB. I did this and my shares immediately all showed up...

Disable SMB2/3 on Windows 10:

sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc.exe config mrxsmb20 start= disabled

Enable SMB1 on Windows 10:

sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc.exe config mrxsmb10 start= auto

So this all works great except one additional hitch:

Windows 10 insists on you using Microsoft live login credentials. After logging in, you can relogin "locally", but then it reverts back at some point when you run an application (like the Store or a number of other Windows 10 applications) that want you to connect into your Microsoft account.

This is a pain if you had your Windows 7 login ID as your Samba login ID on your server as well, since now you're logged in with some kind of email address. So I added the following to my /etc/smbusers file:

my_linux_id  my_ms_live_login_email(id)

Now it all works all the time except one more catch: I use Windows 7 backup/restore to do backups to a drive on my Samba server and, for some reason, it still insists on my being logged in "locally" on Windows 10. So I have to do that manually before I can do a backup. I'm still working on that issue.

A postscript on the Windows 7 backup/restore saga... I couldn't get the Windows 7 backup to work. It would go through part way then claim it couldn't access the drive. I now use the Windows 10 file history, which seems to recognize my Samba drive (with the above described SMB changes) just fine.

This answer was given over 3 years ago. Since that time, SMB 1 has become vulnerable to new malware attacks such as WannaCry and Petya. Microsoft therefore suggests that users stop using SMB. The issue with Windows 10 being able to see Samba shares may now otherwise be resolved since then.

Improve this answer
4
  • @AndrewMorton thanks for the note. My answer is now 3 years old. The SMB 1 solution was suggested in the Windows 10 forum I linked. Not sure but it may have predated the malware you mentioned.
    – lurker
    Commented Sep 30, 2018 at 15:12
  • This answer is nearly 3 years old. We can't be expected to update older answers, with regards to threats that did not exist, when the question and answered were written.
    – Ramhound
    Commented Oct 1, 2018 at 15:29
  • @Ramhound I agree. My answer was just downvoted yesterday for suggesting SMB 1. I added an edit to make sure that users are now aware of the threat. But certainly keeping old answers up to date isn't generally practical.
    – lurker
    Commented Oct 1, 2018 at 16:24
  • You can't be expected to update every answer, once new information comes to light, there is nothing wrong with this 2015 answer. Since Samba has supported SMBv3 since 4.3, I would argue, that a new answer indicating that fact wouldn't be apprpriate either (as you pointed out that fact and it wouldn't provide any new information).
    – Ramhound
    Commented Oct 1, 2018 at 17:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .