Skip to main content

Latest build no longer sees my NAS in recovery environment

Thread needs solution
Forum Member
Posts: 12
Comments: 62

I just updated to the new build of ATI and re-built the recovery USB. I'm using the simple method for WinRE.

It boots fine but can no longer see my NAS. I cannot access it via UNC in the browse dialog either. 

I tried to look at it via the command prompt, but received an error saying that my NAS uses SMB1 and I need SMB2 or later. Is this a new requirement in the most recent recovery media, or is that message just a red herring? I understand my NAS is old but it works fine from within Win 10. 

Thanks for any help you guys may be able to offer. 

Best regards,
Philip

0 Users found this helpful
Forum Hero
Posts: 36
Comments: 7247

#1

Phillip,

First time I have seen this reported, interesting indeed.  Windows security model starting with the Creators editions of Windows 10 deprecate SMB 1.0 and default to SMB 2.0 or above.  If you have upgraded Win 10 to a Creators edition, 1703 or 1709 this would impact WinRE in this regard.

I could only suggest using WinPE with an ADK earlier than Creators editions to build media or use the Linux based version in the Media Builder tool.

Forum Member
Posts: 12
Comments: 62

#2

Thanks Enchantech.

Curious though - if the new build of Win 10 is the issue, wouldn't I also be unable to see my NAS from within my regular Windows environment?

I'll also give the Linux environment another go - it's probably fine, but who knows if its getting the same level of support now that ATI has moved the default to WinRE. 

Best,
Philip

Forum Hero
Posts: 36
Comments: 7247

#3

Curious though - if the new build of Win 10 is the issue, wouldn't I also be unable to see my NAS from within my regular Windows environment?

 This is why I said "interesting indeed".  The implementation of the deprecation of SMB 1.0 is kinda odd.  What they say is that if you install a clean Creators Edition of Windows 10 that SMB 1.0 is removed from the installation by default.  If you upgrade to a Creators edition and SMB 1.0 is installed (default) and enabled (in use) then SMB 1.0 will remain on your installation unless it is not used over an extended time period (whatever that is) then it will be removed from your installation.

How all that relates to WinRE is a mystery, I can not find anything out about that to date!  Your error indicates that WinRE lacks (not installed) SMB 1.0.  So my guess here is that an upgrade to a Creators edition of Windows 10 will ascertain if SMB 1.0 is or has been in use on the system.  If yes then it is left as is and the user is none the wiser.  If SMB 1.0 is not or has not been in use on the system then the upgrade will remove (not install actually)  SMB 1.0 during the upgrade process.  Now you have found that if using the WinRE (Windows Recovery Environment) it says that support is not present and SMB 2.0 needs to be used.  Does this mean that this is an oversight by MS developers? Possibly!

Since your NAS device uses SMB 1.0 obviously and cannot negotiate a higher connection, then the connection fails.  When you are logged into your regular Win 10 install, SMB 1.0 is still present and you can access your NAS without issue. (Sneaky Mr. Softie)!

So that leaves you the user in a tough spot.  Having an old NAS is just a part of the issue here.  Since that is your main concern I think your options are to use WinPE from an ADK of a pre-Creators Edition Win 10.  Having said that, you might get by with the 1709 ADK.  I say that because I have WinPE 1709 which does not complain about SMB 1.0 but then I do not have any devices using the SMB 1.0 Protocol so that may be why I do not get any errors.   You might also use the Linux based media, I say might as driver support is limited and so it might not suit your needs.  Another option would be to by chance, if you are lucky, the manufacturer of your NAS might have released a firmware update that might upgrade the SMB Protocol on your NAS to version 2.0 or above which in theory would solve your problem.

I my case this SMB issue has bitten me twice.  The first time was when Windows 10 was still in BETA and I was testing it.  When 10586 version arrived anyone using a Linux based NAS and/or any legacy devices that used SMB 1.0 or any Windows machines in a LAN that were Windows XP or Server 2002 or older found that they could no longer find these devices in Windows Explorer.  Even Windows 8, 8.1 and 10 machines could not see each other in some cases.  This was a result of the fact that Windows developers left out Device Discovery and File Sharing from the SMB 2.0 and above Protocols!  In a later release after a huge outcry from the community they release a fix for the issue which was nothing more than to install SMB 1.0 on all machines which fixed the problem.

Having not fixed the problem though is a security risk for MITM (Man in the Middle) attacks as the SMB 1.0 Protocol does not use a secure negotiation of connection.  So the wizards at MS decided to once again remove SMB 1.0 from Windows 10.  Well, for me I run a Linux based NAS server in my LAN.  Now I can enter the hostname in an Explorer Window address field and get the server to show up in Explorer and I can then connect to its shares but that is not convenient to say the least.  So after much research and experimenting what I have now is the SMB Protocol is installed on my machines but, I have disabled the SMB 1.0 Server and Client parts of the protocol.  This leaves the discovery and file sharing features of the Protocol available and working so that all my devices appear in Windows Explorer.  Since none of these devices use the SMB 1.0 Protocol I am not worried about an attack by compromising SMB 1.0.  If this were in a business environment where a WAN was involved however it would be another story!

Forum Hero
Posts: 68
Comments: 8127

#4

Enchantech, I think you nailed it with the removal of SMB v1 in Windows 10.  If using Windows ADK 1709, or the default WinRE of Windows 10 to build the recovery media, SMB v1 is left out now.

There is a work-a-round... build with ADK instead, but use 1703 or earlier

Alternatively, one could make these changes to their winPE once booted...

http://www.vacuumbreather.com/index.php/blog/item/54-enabling-smbv1-in-mdt-winpe-boot-images

pulled from...

https://social.technet.microsoft.com/Forums/en-US/ead5320c-6204-45cf-87ba-24edc674dd64/is-there-a-way-to-enable-smb1-in-winpe-adk-1709?forum=mdt

Forum Hero
Posts: 36
Comments: 7247

#5

Bobbo,

Thanks for the links and confirming my suspicions.  I did some searching but did not run across the links you provided.  Great info, thanks for posting!

Forum Hero
Posts: 36
Comments: 7247

#6

Did some reading today on the current release of Windows Insider builds for version 17063.  If you are using Homegroup now in a LAN this new release is doing away with that feature.  According to the article I read the file and printer sharing made possible by Homegroup is now available natively in Windows 10 thus no need for the Homegroup with this release.

This change will impact the user base for sure.  According to the article in order to use the file a printer sharing features of Windows 10 with this release you need to have your Microsoft account involved to do so!  I find that unacceptable as I view it as an intrusive requirement by MS for me to make use of my LAN which I have a good deal of dollars invested in!  I may have no choice here but I do think that MS is dead set on users having no choice in what platforms they use!  purposely hobbling Linux based devices to an unusable state in a Windows environment I find disgusting yet it appears that is where this is all headed.  Anyone wanting to network on a LAN must move to Win 10 and all devices must be Windows based.  If not things will not work as expected!  

Thanks MS!

Forum Member
Posts: 12
Comments: 62

#7

Thanks all for the background and helpful advice. I was able to download and install the 1703 ADK and build the recovery environment from that. The Acronis UI actually makes it really easy to do so once you realize that this is what is required. This version of the RE booted and saw the NAS just fine, so all is well for now. 

I understand deprecating older protocols that are potentially a security risk, but would prefer the choice to re-enable them at my option and with suitable warnings about the security implications. This new path MS is on feels a little more like MacOS than Windows. Apple has been rather aggressive in deprecating older tech, with or without security issues, while I think one of the strengths of Windows has historically been the strong legacy support and attendant continuity. Will be interesting to see how this plays out. 

Anyway, thanks again to all for the assist. 

Best,
Philip.

Forum Hero
Posts: 36
Comments: 7247

#8

Phillip,

Glad you got the ADK option figured out, your right, it is easy once you know that's what to do.

The reality for the user on a home LAN is that the security threat imposed by SMB 1.0 is negligible as a LAN is a "closed" network, not subject to an open insecure connection.  If you are mobile and regularly access public networks is where the issue is most prominent.  If your laptop becomes infected and you carry that home to your LAN this is a concern as well.

Best advice I can give is first, if you have a small home network invest in the best router you can afford and use it as a connection to your internet ISP no matter if the equipment the ISP provides for multiple device connection or not.  Good routers have hardware firewalls which offer great security to a LAN.  A switch is also a good investment so that you can have extra spare connections to the router.  Wireless of course needs to be run in a secured mode as well which most users already know.

I also recommend a software firewall installed on each computer on the LAN.  This can help in defending the LAN connected computers from infecting each other as well as attached devices from spreading malware.

Additionally, to the extent possible insure that connected devices that use Windows SMB can negotiate the highest level of the SMB Protocol possible of which SMB 3.0 is currently the highest.  Linux based device use SAMBA which is the Protocol used to communicate with Windows SMB but has way better security built in to the standard.  Currently SAMBA version 4.0 and its dialects are the highest in the chain.