Windows unavailable network drive handling

[watercooled]

So I have some SMB shares mapped to drive letters on my system, however unless I'm missing something, Explorer seems to have really annoying way of freaking out when they're unavailable.

For example, if I boot while it's unavailable the login takes significantly longer. Or if it becomes unavailable while already booted, doing something like dragging a file into an Explorer window and just passing over one of the unavailable drives, Explorer will hang for a long time (roughly a minute) with the translucent 'dragged' file just hovering over the window.

Also, I've noticed I can get shorter hangs performing similar actions even when it's connected, and the NAS will churn the HDD heads.

It just seems like a very poor way of handling remote drives - always checking for their presence and adding latency to common tasks even while connected. Even Windows' SMB credential management seems completely horrid but that's a rant for another time.


I don't think I'm doing anything unusual with regard to mounting them - just as a mapped network drive. Maybe a login batch script would be a way of avoiding the issue if the share is unavailable at boot but surely something like that shouldn't be necessary considering the popularity of user-friendly consumer NAS boxes? It seems like a massive usability oversight if it needs scripts to resolve it.

[Optimaximal]

You have to consider that Windows > NAS is actually Windows > SAMBA. As robust as it is, you have to remember SAMBA is an open-source backport of SMB, so it's always going to be compromised.

On top of that you have the NAS running power-saving tasks, disk optimisation etc. Are the NAS drives in a particular form of RAID? How fast are the drives (eco drives often have pretty annoying 'wake up times')?

[watercooled]

It's not the NAS or its software to blame, as I said Explorer stalls if the drive is not available i.e. not connected to the LAN/turned off. And for what its worth it happens on Windows shares too.

I didn't say I was using Samba but as it happens I am, but it's not what I'd consider compromised compared to Windows implementations. Indeed, it doesn't seem to display this same weird hanging behaviour as the Windows implementation.

[Optimaximal]

It's not the NAS or its software to blame, as I said Explorer stalls if the drive is not available i.e. not connected to the LAN/turned off. And for what its worth it happens on Windows shares too.

I didn't say I was using Samba but as it happens I am, but it's not what I'd consider compromised compared to Windows implementations. Indeed, it doesn't seem to display this same weird hanging behaviour as the Windows implementation.

Sorry, didn't mean to sound like I was correcting you or anything, just mentioning that pretty much every commercial NAS box out there runs a custom Linux distro that almost certainly hangs off SAMBA in one form or another.

My QNAP (TS-210+) has many grinding hangs whenever I do anything with it other than passively stream, but that's like a combination of the WD Green drives, the asthmatic Marvell CPU or the OS getting ahead of itself with the hundreds of CRON jobs it sets up to make sure all the indexes are up to date.

That Windows gets 'hung up' on network drive investigation is likely down to Microsoft hanging onto some legacy compatibility code from the LAN Manager days. Wouldn't be the first time, eh?

[watercooled]

In my case I'm running Samba under Debian rather than an off-the-shelf NAS, but like I say the remote configuration seems pretty much irrelevant, which is why I didn't go into detail in the OP. It just seemed like I could be overlooking something considering it's so blindingly obvious and frustrating if it really is a bug. Having the UI thread hang when waiting for a response from a disk drive, let alone a network drive with comparatively high latency, seems daft.

Even when attempting to connect to SMB shares, especially over WiFi, you enter the server address then wait for ages. Then enter credentials, and wait for ages. And if you're lucky, an Explorer window will open with the contents. I don't know how they manage to make it so slow when the *Linux* implementation manages it near-instantly!

[Bluecube]

I don't know if this is relevant but I'll share (boom tish!) anyway. I have an HTPC which connects to a Windows share on my server. When I turn the HTPC on it never connects to the share - I always get the message "Cannot connect to shared drive" on boot up. I can only connect to the shared drive on opening up Explorer and clicking on the drive. After that, all's well until the next start up. To get round this annoyance, I created a small script that runs on boot that waits a few seconds then opens the shared drive in Explorer and connects up to it before closing Explorer. This ensures that the shared drive is always available when needed and avoids the issues you're facing.

[watercooled]

Yeah a startup script is probably the way to go, it should at least avoid the massive login delay if the share is unavailable.

[Optimaximal]

A logon script won't necessarily help - if you've got some sort of UI hang when accessing the drives, you're just going to be sat there watching the logon script run (or not, as the case may be) before reaching the desktop. Ok, it may result in your drive being there when you finally connect, but I can't imagine the extra logon time will be bearable.

There's also the consideration that the logon script executes in the SYSTEM context, so you need to fudge the registry to execute such scripts in the user context (see https://support.microsoft.com/en-us/kb/937624/en-us).

Finally, have you scoped out the application and system logs to see if there are any specific mentions of timeouts or unresponsive connections? Have you tried changing the shares around or mapping new shares in Samba? Could be trial and error to see if its one single mapping that is delaying the login or all of them making it progressively worse.

[watercooled]

A script would run in the background after I'd logged in, so I wouldn't be stuck waiting for the desktop to appear, and nor would it hang Explorer - if the share isn't mounted yet it wouldn't affect it. It's no big deal to set it up, I've a few scripts running various other things anyway and was considering 'fixing' it that way as I mentioned in the OP, as I said it just seems silly that the problem exists in the first place and requires bodging.

It's provably nothing to do with Samba, it's a Windows problem. It happens with any number of shares, and includes native Windows SMB shares - but it's a given anyway as it hangs without any possible knowledge of what software implementation is behind the mapping.

Having done some more searching it seems it's a fairly well-known problem and a common solution does seem to be using scripts, with a few interesting ideas including pinging the server first and only attempting to mount if it responds.

It's almost like no-one has told whoever is responsible for the SMB client that things like laptops exist, and may frequently be away from certain networks occasionally.

[Optimaximal]

Fair enough, I was just offering another thread of diagnosis.

Had a fun time at work as we changed the file server - both Windows & countless applications had hard-coded the hostname into the registry in *so* many places, everyone had random hangs all over the place whilst waiting for inevitable timeouts. Ended up having to put a CNAME in Windows DNS to save having to rebuild everyone's profiles.

[watercooled]

It seems like some parts of Windows just haven't been touched for years - this is a problem which has existed since at least Win XP and it's not like network shares are rare.

I could even reproduce this with fresh and completely untouched Windows install on another system so it rules out the possibility of it being e.g. some random setting I've changed.

[Optimaximal]

It's like how key applications (i.e. SQL Server) and systems only support basic Active FTP - an insecure and fundamentally broken protocol that others have been trying to force to be deprecated for *years*.

Likewise for Telnet.

Microsoft just seem to weigh up work vs. annoying existing users and pick the latter (lest they switch platforms).

[watercooled]

OK so I'm revisiting this issue as it's been irritating me again. It turns out only mapped drives cause the issue, not network locations. So if all I wanted to do were use it for copying files in Explorer then that would be problem solved. However, lots of software won't be able to 'see' network locations, one of which is some backup software I use, so that's not an option.

However...

I could work around that by creating a symlink on e.g. my C drive pointing to the shares for these programs to use, and just use the saved network location in Explorer for browsing. I don't suppose if anyone knows of any problems with doing it that way? It's a definite possibility I'll run into some issue and have to revert back, but I might give it a try for a while as the Explorer hangs are really annoying me.

Also I seem to remember reading somewhere that performance can be worse this way for some strange reason, not sure if that's true but I'll be sure to test it.

[BobF64]

Can the software not use UNC paths?

At least if that were an option, the shares would only get accessed when you ran something that tried to use them.

[watercooled]

Can the software not use UNC paths?

At least if that were an option, the shares would only get accessed when you ran something that tried to use them.

Sadly not. But I think the symlink workaround should work, I'm just wondering if there might be some issues with e.g. file permissions.

[herulach]

Do you select through a dialog, or does it need a setting that can't take UNC? If its the former you can map folders on UNC drives to your 'Favourite Locations' which means stuff using the new windows save/open dialogs its only a couple of clicks.