7

After upgrading from Windows 7, a Windows 10 host no longer connects to a share on a MS-DOS 6.22 industrial hardware with net use x: \\smbserver\dxcontrol

It can connect to a Windows 7 host that I'm using temporarily. Both machines have identical sharing information as far as Other hosts on this network (Windows 7, Windows 10, macos) can see both the Windows 10 and Windows 7 shares and connect without issue.

The MS-DOS host also doesn't support authentication, so it requires guest access.

The systems can all ping each other without issue.

Connecting to a Windows 10 share results in the error message: Error 55: This resource does not exist on the network

Which is a different error than I see when trying to use a non existent directory on the win7 machine net use x: \\win7dxbackup\noexist

Error 67: The specified shared directory cannot be found.

And is also different than providing a non existent host:

Error 53: The computer name specified in the network path cannot be located.

I prefer not to use an additional network device like a network drive or linux machine sitting in the corner collecting dust just to share this one directory.

I can see both machines using net view on the MS-DOS host.

Any help is appreciated.

Greg Askew
  • 39,132

2 Answers2

2

Todd Wilcox has the answer. You will have to re-enable SMBv1 on that Windows 10 system. You can do this by going to Control Panel\Programs and Features, and selecting "Turn Windows features on and off" on the left side. Scroll down the list until you find "SMB 1.0/CIFS Server". You can enable CIFS Client too but it shouldn't be necessary.

Like Todd mentioned, using SMBv1 (as well as a DOS system) is VERY insecure and leaves your systems vulnerable to the WannaCry ransomware vulnerability. If this is on a corporate network you would do well to follow best practices and attempt to airgap those two systems at MINIMUM. If this is on your home LAN, well, best of luck!

1

The answer to this problem is to use Windows 10 1803 with no further updates (updates must be frozen after 1803 install). I've tested this in Virtualbox after failing with 1809. SMB1 was either disabled (meaning it could no longer be re-enabled regardless of what method you use) with 1809 or with a minor security update shortly after 1803.

See: https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows