SMB access fails after disabling SMB1.0 on client machine

[Ian Carson]

Hi Guys

I recently innoculated my network against NotPetya by disabling SMB1.0 on all my machines.

This has had the unfortunate effect of making it impossible to map any shares on my FreeNAS machine.

I'm not sure I understand why as my SMB settings on FreeNAS are set to ServerMax=SMB3.

My ServerMin setting is "------"

Has anyone come across this issue?

 

[Ericloewe]

It would help to know what the client OS is...

 

[Ian Carson]

Sorry - you're quite right.

Client is Windows 7

 

[zoomzoom]

This has to do with something in Windows, as it occurs on all versions once smbv1 is uninstalled from the Windows Features panel. Even more frustrating is Microsoft has provided no guidance on what the issue is.

I ended up having to re-enable smbv1 in Windows 10 because it also regulates sharing between the OS and Hyper-V VMs, even though Windows 10 should be using smb3 (I'm curious how it's going to go when the next major update defaults smbv1 to be uninstalled).

 

[bigphil]

Something else is going on here. You stated your client is Windows 7...this supports up to the SMB 2.1 dialect. I just tested a Windows 7 SP1 box (all of the latest updates installed too), SMB1 lanmanserver disabled and SMB1 client disabled on the Windows 7 box, rebooted it and can still successfully connect to an SMB share on my FreeNAS 9.10.2-U5 system. You can use Wireshark with Windows 7 to determine which dialect your Windows 7 client and the FreeNAS server are using by following this article. Are the clients in a workgroup environment or Active Directory? If using AD, make sure not to disable SMB1 on the domain controllers as this can cause issues (just make sure they are patched with the latest Windows updates).

 

[zoomzoom]

@bigphil Any chance you have a Windows 10 machine to test that out on, as I spent a little over 4 hours troubleshooting 2 days ago and couldn't determine why exactly disabling smb1 would result with the same issue as the OP.

 

[bigphil]

I don't currently have one running, but I can spin one up. Is your Windows 10 box on the latest build?

 

[zoomzoom]

It is (build 15063.448], thank you =]

If you are still able to use smb with smbv1 disabled through Windows Features after a reboot, could you please printout (or screenshot) the services that are currently set to atuo, auto delay, manual, and disabled?

• I currently have a few extra services disabled, such as the services for Windows Media Network and HomeGroup. I can provide a full list upon request.

 

[bigphil]

I'm building the Windows 10 box now and I'll report back my findings. Only difference so far is that I'm using FreeNAS 9.10.2-U5 and you both seem to be on 11.

 

[zoomzoom]

While my issue does mirror @Ian Carson's, when smbv1 is disabled [uninstalled] via the Windows Features panel (Control Panel\All Control Panel Items\Programs and Features -> Turn Windows Features On or Off), it prevents all SMB share connections, server and client alike, not just those with FreeNAS.

• For example, local shares on the Windows host can no longer be accessed via SMB in Hyper-V VMs (via the LAN IP or the internal virtual share interface). For some reason, disabling smbv1 prevents Windows from acting as an SMB server or client in Windows 10, and I couldn't find any documentation online detailing exactly why this is occurring in Win 10, nor how to resolve the issue.
  • My understanding is SMB3_11 should be utilized as the default protocol in Windows 10, with the negotiation of the protocol between SMB server and SMB client being the highest supported version between the two (which should be SMB2 at the lowest). I do know smbv1 is disabled by default in a clean install, although that may not be the case for everyone since I use MDT to deploy Windows to my personal PC.

 

[bigphil]

@zoomzoom , have you tried just disabling SMBv1 server and client vs uninstalling it?

 

[bigphil]

Well, I built a Windows 10 Pro box and installed latest updates, uninstalled SMB1 via add/remove features, rebooted...I can still connect to my FreeNAS via SMB and the dialect shows 3.1.1. Works as expected.

 

[Ian Carson]

Something else is going on here. You stated your client is Windows 7...this supports up to the SMB 2.1 dialect. I just tested a Windows 7 SP1 box (all of the latest updates installed too), SMB1 lanmanserver disabled and SMB1 client disabled on the Windows 7 box, rebooted it and can still successfully connect to an SMB share on my FreeNAS 9.10.2-U5 system. You can use Wireshark with Windows 7 to determine which dialect your Windows 7 client and the FreeNAS server are using by following this article. Are the clients in a workgroup environment or Active Directory? If using AD, make sure not to disable SMB1 on the domain controllers as this can cause issues (just make sure they are patched with the latest Windows updates).

You make an interesting point regarding the SMB level of the DCs. I'll go an check this out as an experiment. It kinda negates the NotPetya "innoculation" though as that particular ransomware utilizes flaws in SMB1 to transmit itself around a network...damned if you do, damned if you don't I guess :)

 

[bigphil]

It kinda negates the NotPetya "innoculation" though as that particular ransomware utilizes flaws in SMB1 to transmit itself around a network...damned if you do, damned if you don't I guess :)

Microsoft released a patch that fixed the vulnerability in the SMBv1 code well before the last two big ransomware attacks hit...people just failed to install it in time.

 

[R.G.]

I'm glad I stumbled onto this thread. I've been pounding google and the FreeNAS forum search for about four days now, trying to make my previously-rock-solid backup to a FreeNAS server work. I'd welcome any advice or pointers. All I can add to the conversation is a pile of things I've tried that did not work.

First, all this is complicated by a disk issue in my FreeNAS server riding in while I was grappling with de-activating SMBv1. I'd been having intermittent issues with one drive, and only after some days of part-time debugging efforts found that the drive that was dropping in and out of the pool was just fine - I had an intermittent SATA cable. That stretched out the time period to recognize that the SMB problem was lurking in there.

I was on 9.10 at the time, having lagged well back after having been burned a bit in the FreeNAS 10 issues. But along the path, I decided that perhaps this issue had been fixed, and upgraded to 11.1-U5. No real change in the SMB situation, but the upgrade appears to have been automatic and completely error free from the checking I've done on the FreeNAS system itself.

I have an assortment of Win10 and Win7 machines, and even a couple of XP machines for special purposes on my house net. While doing the SMBv1 disable on the gaggle of machines, I found that various combinations of enable/disable/features/permissions and so on would allow the Windows machines to see one another on the local net. I finally got them all to deal with one another over SBMv2...v3. What made that work was figuring out from hints on the web that discovery of other machines on the local net between Windows machines had to be moved from NETBIOS discovery to WSD discovery. I was able to engage the "discovery method" column in Windows' network and sharing panel to track down things that were being discovered by NETBIOS and change that in all but one case I'm still fighting.

It was only after that got cleared up that I was able to get a solid reading that none of my auto-backups were finding and using the FreeNAS server. I tried several variations of tinkering the FreeNAS setups to get SMB to work with non-SBMv1 Windows machines. Nothing worked. Although the Windows machines were finding each other over SMBv2... discovery methods, FreeNAS, even with the highest SMB level carefully engaged and (re)checked would never be discovered by the Windows machines.

I got trapped in the "enter your credentials again" permissions loop again. Still unsolved, but very intermittent.
I flipped the "local master" enable on FreeNAS several times. No change. I've read both that a Windows machine must be the local browser master, and that the server must be. Neither seemed to help.

I've been through the enable/disable powershell stuff on Windows machines. No change.

Re-enabling SMBv1 will - intermittently - re-enable access to FreeNAS for lifeboat-style backups. It's not a solid fix, probably because I didn't write down exactly what I'd changed in the tangled path to get to where I was when I got it to work.

This has all led me to believe that Windows has moved to a proprietary WSD discovery method that works with Windows SMBv2 and later, but that FreeNAS, even with SMBv2 and following, cannot yet deal with. At least that's my current working theory.

I'm stuck there. I'm really familiar with ferreting out settings and such, but have no ability do dig deeply into the coding. If you have any pointers, please...

 

[R.G.]

One more layer deep: I decided to re-enable SMBv1 on my two Win10 machines to see if I could spot some kind of issue in Samba logs. Having done that, one Win10 machine is fine now, can access the FreeNAS machine shares and the machine appears in the network portion of File Explorer. The other Win10 does not see the NAS. My backup program on the Win10 that cannot see the NAS gives me a repeated credential failures pop up as the backup program tries to access.

I see in the Samba4 log many entries that look like this:

Code:

[2018/07/08 00:06:41.682245,  0] ../source3/winbindd/winbindd.c:279(winbindd_sig_term_handler)
  Got sig[15] terminate (is_parent=0)

In log.smbd I find many of:

Code:

[2018/07/08 17:39:22.120450,  1] ../source3/smbd/service.c:521(make_connection_snum)
  create_connection_session_info failed: NT_STATUS_ACCESS_DENIED

I don't have the skills to parse that out to a cause. A guess is some kind of authentication issue that I can't find yet. I've checked and rechecked the windows credentials and entered every possible host and user name/password that even might apply.

 

[R.G.]

One more step. Tried re-enabling SMBv1 to get a backup run done. Still cannot access the FreeNAS network shares by backup program, nor does the FreeNAS server appear in the File Explorer network list.

However, un-checking "local master" in FreeNAS SMB setup allows the FreeNAS server to appear in the File Explorer network list.

Unfortunately, trying to actually access files on it results in the never ending loop of windows security popups complaining that I have to enter credentials, and successor popups saying that those are the wrong credentials. Again, I have tried all variants of the real, true, verified username and password, with all variants of the hostname or local IP address as a qualifier.

So I can "see" the FreeNAS server, I just can't actually access the share once I can access the server.