I found yet more info on why my network sharing went to ... er, heck when I followed the desperate warnings about SMBv1 being an open door for ransomware. I suspect that this confusing (to me, a networking user, not a cognoscenti) pile of overlapping and interacting issues is behind quite a few of the posts here and many places over the net.
A lot of it has to do with the fact that you have to go learn the innards of networking to understand how to play the game. Some history, too. I studied quite a few treatises on networking in general, FreeNAS and FreeBSD, NETBIOS, SAMBA, Windows vs Unix permissions, routers. Understanding didn't begin until I read this:
http://janbacon.blogspot.com/2015/04/disable-netbios-enable-dns-with-dd-wrt.html
It turns out that SAMBA shares can be based on NETBIOS or TCP. SMBv1 runs on NETBIOS only (if I read the stuff correctly) as does the network browsing function of Windows. Turning off SMBv1 disables network discovery of shares by NETBIOS. This ought to leave SMBv2 and up running just fine, discovering network shares by other means. In fact, if I understand it right, both NETBIOS discovery and the WSD and SSDP discoveries run a race and the first to report back a share is used to access that share. In my case, even with WSD and SSDP running and discovering all the other shares, my FreeNAS server is always discovered by NETBIOS.
I spent probably more than four hours trying to disable NETBIOS responses from FreeNAS before concluding that it was not possible or too hidden. I also looked for some way to make the >minimum< level of SMB be SMBv2. Never found it.
The other means is TCP over port 445. Turns out that TCP over ports 13x and 445 is commonly blocked on routers, including mine, because of the historical vulnerabilities that have happened with v1 and the 13x ports. SMBv2 and up require TCP over 445 to do network discovery, so it does not work unless you open port 445.
Opening TCP port 445 in my client firewall duly re-enabled discovery of my freenas server and the shares inside it, even with SMBv1 disabled, which had been impossible before.
I still get the bad-credentials loop and can't actually access the shares yet, but I can reliably see them on my local net. More work to do to discover the next problem.
This conundrum seems to be the result of at least three different and overlapping issues. Microsoft, however good- or ill-intentioned you think them, advised removing SMBv1 because of the huge vulnerabilities it opens. However, with 30 years of SMBv1 always being there, it's become part of the mental ecosystem, so very many applications and devices use it. Routers can and often are set up to block TCP over 13x and 445 because of the vulnerabilities. Firewalls are often (like the one in my client) set up to block them for the same reason.
I think the myriad of issues with SMBv1, Windows, and FreeNAS CIFS shares is, at its root, an overlapping of good-intentioned restrictions and that whomever-replies-first share discovery stuff in Windows. It makes getting this all to work without SMBv1 be like the only way to get to the final level is to hold the gold key in your left hand, spinning right three times, and saying "hello" to the doorman.
Well, OK, maybe just knowing more about networking than I do.
I still get password fails, access denied, wrong username or password, etc. replies when I actually try to access the share, but it's because I have not stumbled on the correct green-apple-twostep dance of permissions to get there yet. Or another layer of access restrictions.
A lot of it has to do with the fact that you have to go learn the innards of networking to understand how to play the game. Some history, too. I studied quite a few treatises on networking in general, FreeNAS and FreeBSD, NETBIOS, SAMBA, Windows vs Unix permissions, routers. Understanding didn't begin until I read this:
http://janbacon.blogspot.com/2015/04/disable-netbios-enable-dns-with-dd-wrt.html
It turns out that SAMBA shares can be based on NETBIOS or TCP. SMBv1 runs on NETBIOS only (if I read the stuff correctly) as does the network browsing function of Windows. Turning off SMBv1 disables network discovery of shares by NETBIOS. This ought to leave SMBv2 and up running just fine, discovering network shares by other means. In fact, if I understand it right, both NETBIOS discovery and the WSD and SSDP discoveries run a race and the first to report back a share is used to access that share. In my case, even with WSD and SSDP running and discovering all the other shares, my FreeNAS server is always discovered by NETBIOS.
I spent probably more than four hours trying to disable NETBIOS responses from FreeNAS before concluding that it was not possible or too hidden. I also looked for some way to make the >minimum< level of SMB be SMBv2. Never found it.
The other means is TCP over port 445. Turns out that TCP over ports 13x and 445 is commonly blocked on routers, including mine, because of the historical vulnerabilities that have happened with v1 and the 13x ports. SMBv2 and up require TCP over 445 to do network discovery, so it does not work unless you open port 445.
Opening TCP port 445 in my client firewall duly re-enabled discovery of my freenas server and the shares inside it, even with SMBv1 disabled, which had been impossible before.
I still get the bad-credentials loop and can't actually access the shares yet, but I can reliably see them on my local net. More work to do to discover the next problem.
This conundrum seems to be the result of at least three different and overlapping issues. Microsoft, however good- or ill-intentioned you think them, advised removing SMBv1 because of the huge vulnerabilities it opens. However, with 30 years of SMBv1 always being there, it's become part of the mental ecosystem, so very many applications and devices use it. Routers can and often are set up to block TCP over 13x and 445 because of the vulnerabilities. Firewalls are often (like the one in my client) set up to block them for the same reason.
I think the myriad of issues with SMBv1, Windows, and FreeNAS CIFS shares is, at its root, an overlapping of good-intentioned restrictions and that whomever-replies-first share discovery stuff in Windows. It makes getting this all to work without SMBv1 be like the only way to get to the final level is to hold the gold key in your left hand, spinning right three times, and saying "hello" to the doorman.
Well, OK, maybe just knowing more about networking than I do.
I still get password fails, access denied, wrong username or password, etc. replies when I actually try to access the share, but it's because I have not stumbled on the correct green-apple-twostep dance of permissions to get there yet. Or another layer of access restrictions.
