Re: Windows 10, mapping drive unreliable, slow or fails

Dorset_tx · ‎2018-08-23

I have had onging issues with mapping drives to or accessing my NAS (OS 6.9.3) since switching to Windows 10. Each update to Win 10 aggravated the problem with the latest update to 1803 making the process more miss that hit.

To be clear this is not a file transfer speed issue. If I get a connection file transfer is fast and reliable. It is the initial connection process that is either very slow or fails.

Having tried endless ideas from posts, with little success I found that if you map a drive by IP address. I.E: \\192.168.0.123\ShareName this works reliably. Suggesting the issue is a name resolution issue.

As an alternative to specifying the IP address adding a relevant entry to the Hosts file seems also to fix the issue.

Richard

StephenB · ‎2018-08-23

Re-enabling the SMB 1.0 client might also help, since it drags the legacy windows discovery mechanisms with it.

Dorset_tx · ‎2018-08-24

Thanks,

given that SMB1 has been deprecated because of its poor security & exploitation by malware possibly not a good idea on a portable device that gets connected to other networks in its travels.

I think Win 10 resolves names via DNS or WSD by default. The root cause is probably something to do with the DNS config of my router meaning the NAS doesn't always get registered. If I crack that I will post but in the interim the Hosts file is a simple workaround for anyone else with this problem.

Retired_Member · ‎2018-08-24

Hi @Dorset_tx, thanks for letting know. To control some of the parameters of protocol SMB through the graphical ui you might want to checkout app "smb plus". If you already are using that, don't feel bothered.

StephenB · ‎2018-08-24

@Dorset_tx wrote:

I think Win 10 resolves names via DNS or WSD by default. The root cause is probably something to do with the DNS config of my router meaning the NAS doesn't always get registered.

The NAS will respond to WSD discovery requests.

One alternative to enabling SMB 1 is to go to the TCP/IP properties, and look at the WINS tab. The WINS configuration will be blank, but there are a couple of netbios name options lower down. It defaults to getting netbios names from DHCP (not the same as DNS), but you could also try setting netbios over TCP/IP and see if that helps.

In any event, ping -a nas-ip-address will show you the hostname that the PC has (if any). But I have seen times where that resolves correctly, but \\hostname in file explorer still fails.

There are some fairly recent reports with Windows 10 failing ping with case-sensitive names. They are a bit inconsistent - some saying that their systems only work with ping NAS (uppercase), others saying that it only works with lowercase or mixed case (ping nAs for instance). So that's another thing you could look at.

FWIW, Windows network discovery of linux systems has been hit-or-miss in Windows for a long time (well before Windows 10). I've gotten into the habit of just using the IP address (and have set up shortcuts that do that on our family PCs).

@Dorset_tx wrote:
given that SMB1 has been deprecated because of its poor security & exploitation by malware possibly not a good idea on a portable device that gets connected to other networks in its travels.

Normally Windows will classify those networks as public (certainly the wifi connections), and on public networks SMB defaults to off.

Dorset_tx · ‎2018-08-24

Thanks,

the information about netbios name resolution via DHCP being the default has I think unlocked the mystery. The NAS doesn't appear in the DHCP client list on the router that acts as the DHCP server. The NAS is configured to use DHCP and has a reserved IP address. Other devices also configured this way do appear in the list but it may be that as the NAS is always up and connected gets timed out for some reason.

At the moment the entry in the Hosts file seems to be a reliable fix, making accessing the NAS virtually instant when before even if when it was accessible there would be long pauses in file open/save dialogues.

schumaku · ‎2018-08-24

There is nothing like a NetBIOS name resolution over DHCP. Let's break down things a little bit...

1. If your NAS (configured to a DHCP client) does not show up in your router DHCP table or attached devices or however this is named, something is wrong. This does indicate there is a problem with the DHCP process overall, or with it's regular renewal on your (W)LAN.

2. If your Windows systems struggle to discover or run the WS-Discovery based name resolution, something is wrong. This does indicate there is a problem with IP Multicast on the (W)LAN.

3. If your Windows system fail to recognize NetBIOS host announcements for discovery (permitting the Windows Features "SMB 1.0/CIFS File Sharing Support" enable both "SMB 1.0/CIFS Client" _and_ "SMB 1.0/CIFS Server" - the later one is required since newer Windows 10 builds because of the NetBIOS host discovery and name resolution is part of the server) indicate there is a problem with your network IP broadcast.

4. If your Windows system fail to resolve host names using NetBIOS (again permitting the Windows Features "SMB 1.0/CIFS File Sharing Support" enable both "SMB 1.0/CIFS Client" _and_ "SMB 1.0/CIFS Server" - the later one is required since newer Windows 10 builds because of the NetBIOS host discovery and name resolution is part of the server) indicate there is a problem with your network IP broadcast.

Some routers are maintaining some special local DNS domain, permitting to resolve names using DNS. The host table is automatically propagated from hostname and IP address provided during the DHCP handshake. However, DNS does (by default) always come as second or third, after WSD, after NetBIOS.

Leaving some crazy Internet "security" garbage bugware away, my guess there are some very basic L0...L2 problems on your local network.

Tell us more anbout your network, your router, switches, powerline communication, wireless bridges, ... all can be common sources of problems you experience.

Dorset_tx · ‎2018-08-24

The network is fairly simple:

TP Link TD-W8970 (ADSL Modem Router & Wireless access point & 4 wired 10/100 ports). Netgear 5 port 10/100 dumb hub uplinked to TP Link 10/100 port.

NAS connected to 10/100 port on hub.

Win 10 Desktop connected to 10/100 port on hub.

Win 10 Surface connected via wifi.

TP Link LAN is 192.168.1.1 (255.255.255.0)

All IPs via DHCP with reservation for NAS.

All used to work with zero problems with Win 7. Early versions of Win 10 too.

1709 update made discovery slow and connecting failed occasionally.

1803 update failure rate went to 2 out 3 attempts.

NAS always appears (after +60s) as a device in Explorer > Network but when you try to expand / connect, connection fails with error message and then network troubleshooter which finds no problem.

Since adding a Hosts file entry for the NAS. Instant access, zero connection failures.

StephenB · ‎2018-08-24

@schumaku wrote:

There is nothing like a NetBIOS name resolution over DHCP. Let's break down things a little bit...

This is the setting I was talking about. By default, DHCP tells Windows whether to enable NetBIOS over TCP/IP or not. This is a "Vendor Class" option. I have no idea whether Netgear routers do this, but none of them expose a setting for it. I agree this setting isn't the same as NetBIOS name resolution over DHCP - I mis-spoke above.

@schumaku wrote:

2. If your Windows systems struggle to discover or run the WS-Discovery based name resolution, something is wrong. This does indicate there is a problem with IP Multicast on the (W)LAN.

Maybe. Or there's an interoperability issue between Microsoft and Debian Linux, or a bug in the NAS or Windows.

What I do know is that I've seen lots of discovery issues posted here, and occasionally seen them myself. I've also seen them posted on other forums (often ReadyNAS isn't involved). Printer discovery is related, and that's certainly not perfect either. Sometimes the issues are only in the network tree shown in file explorer, sometimes they are more basic Often they occur on some PCs on the network, and other near-identical PCs work fine. Often failures are intermittent. I've never a clear explanation from Microsoft on how to resolve this, but I've seen plenty of complaints.

Personally I reached the conclusion log ago that the Windows IP stack is just somewhat broken in this area. My NAS have reserved IP addresses, and my pattern is simply to use them. So perhaps it's working perfectly on my current network, perhaps not.

schumaku · ‎2018-08-24

@StephenB, a litle excursion into our common history (as I know we're about in the same generation):

That DHCP vendor option (and the still available controls on the interface properties) is used to disable NetBIOS over TCP/IP - so NBF (NetBIOS Frame Protocol) would be used instead - as it was in the good old times of 3com/Microsoft LAN Manager / IBM LAN Server et all doing communication using 802.2 LLC (link layer control) protocol. There were similar alternate protocols be used, ie. Novell NetWare NetBIOS-over-IPX/SPX, or Digital Equipment Corp. LAST (Local Area System Transport) - as on old DECie I have to pint out that we won any performance comparisons back at these golden times. As all this is history, that DHCP vendor option as well as the controls to disable NetBIOS over TCP/IP have no relevance - as NetBIOS over TCP/IP is still core. As NetBIOS discovery and name resolution was not routable, WINS was introduced as a helping hand between networks. Just the NetBIOS host announcement and name resolution was defined obsolete along with the Microsoft phase-out of SMB 1.0/CIFS (still required for legacy NAS, Netgear ReadyShare, ...) and replaced by WS-Discovery.

We have some ~100 various storage systems announcing theself by NetBIOS (the legacy stuff) or WSD (the current NAS OS from Asustor, Netgear, QNAP, Synology, ...) and many network devices/printers doing SSDP in the playground - when bringing a Windows 10 system into that LAN (by WLAN or LAN), all these devices/services show up within a few seconds maximum. The only devices which don't show up (neither as a NetBIOS announcement [no idea why, some Netgear ODM engineers peeked and poked around remotely but were not able to figure out] nor by WSD [still not implemented] are Netgear's Nighthawk router ReadyShare (while the related UPnP SSDP announcement show up correct and in time).

The "everyday" network is built on Netgear XSxxxT and GC (Insight managed), plus some XSxxxE/GSxxxE (like the XS724E or GS110EMX) for edge usage switches, some standalone managed WAC730, and a bunch of WAC505/510 all in AP mode representing a typical SMB environment. Another network is built based on a R9000, GS808E (S8000), GS810EMX (SX10) and GS908E so a "consumer" class network linking in on alternate interfaces to a bunch of NAS, too [and psst, some edge networks for testing say powerline are linked up over a VLAN on the core network].

On all these, we can ad-hoc switch our Windows 10 physical machines or test VMs - the NetBIOS, WSD, and SSDP pop-up very reliably. There is a litle impact if the Windows 10 system virtual memory usage is high, NetBIOS devices can become cumbersome to be visible in Explorer.

StephenB · ‎2018-08-26

My own home network is currently using an Orbi for the router (RBK50), with several switches. The core switch is a GS728TPv2; the RN524x and RN526x are connected to an XS708e (since they use 10 gigabit). One PC also has a 10 gig card, and is connected to that switch. As I noted, I haven't tried to seriously troubleshoot Win10 WSD with SMB 1.0 disabled, because all the PCs access the NAS using desktop shortcuts that use the IP address of the main NAS (the RN526x).

jonnyjain · ‎2018-10-25

hi