NAS access via Win Explorer issues

I assume you've tried disconnecting and remapping the QNAP NAS via Windows Explorer ?

Also you might want to look at the network devices listed by checking your router's homepage. Is it possible that the i.p. address has changed (e.g. if router has been restarted) or that the QNAP is listed under a different network name e.g. QNAP_NAS instead of its i.p. address in which case you would have to map the drive folder as \\servername\multimedia

Greg, have you updated or restarted the QNAP recently? When I did I also lost access to my network locations.

I resorted to disabling the Microsoft Networking on the QNAP and then re-enabling. That did the trick for me.

HTH

it's definitely an issue with my main laptop as two other Windows devices on the same network have no such issue. Must have something to do with security, I found a thread suggesting some parameter changes in security settings: secpol.msc : local policies -> security options which is quite esoteric for me... I will give it a try

If you can run Policy Manager then you're using Windows Pro - do you have a DC on the network?  If so are you using AD on it (or another LDAP server)?
Windows Pro isn't really designed to work with home networks and Homegroup style network security.

Messing about with Security Policies isn't a good idea if you don't know what you're doing - it's entirely possible to lock out your Administrator account and then you'd have to reinstall the OS (and subsequently take ownership of all your local data again, but this time doing it actively)

Have you tried unmapping the drive (use the 'net use' command if you can't clear it from the UI or still have the issue after clearing it via the UI )

Do you have anything in the LocalHosts file?

Is there a reason for NOT using DHCP?  Have you restricted the DHCP allocation range in the router (or other DHCP server)?

Can you ping the NAS by name (rather than by its IPv4 address), if not then you have a DNS lookup problem.  If so look at the DNS and Gateway settings in the network configuration of the client PC on which you have a problem.

Hi Huge, to your questions:

1. I have indeed tried unmappping the drive, no issue there. Mapping it back is the issue :-)

2. tried "net use" already yesterday  - returns error 64 which when researching got me to the thread I mentioned above

3. if by "not using DHCP" you mean "why do I have a fixed IP": because network search does not work with my (company) laptop unless I temporarily disable the firewall; fixed IP allowed me till now to access those other network devices vie Windows Explorer even with firewall "on".

4. will try pinging the NAS with the "logical" name once back from work tonight. DNS set up is automatic on my laptop and "fixed" on the QNAP (I recall primary  being 192.168.1.1 (which is the router IP) and secondary 8.8.8.8)

I would be tempted to suspect the latest security update but then I have colleagues at work with the same Windows config who are still happily accessing their NAS (which means there is still hope!)

Hi Greg,

From Point 2...
I don't use QNAP (I use a Synology), so I don't know, but can you disable SMB2 file access on the QNAP, and leave just the SMB1 file access protocol active?

From Point 3
This could be due to a security policy downloaded from the companies policy servers,  If you try to override this (or make any changes to the active local policies on the PC) your tech support may get mighty pissed (and you may well not have enough privilege to do so anyway), and they may report you to internal affairs* / internal security* / higher management* for trying to bypass company security protocols.

As this is a company laptop, the best thing is to ask your tech support people for help.

* Delete as applicable!

thanks Huge, I did try a few "exotic" patches (which came perilously close to attracting IF) to no avail - yet somehow your post prompted me to change the DCHP settings from fixed to dynamic IP on the NAS:  low and behold Windows Explorer now works!... mounting the NAS using the logical name also works. Tomorrow I will attempt the same on the Seagate...thanks a lot. Still no idea why this works but happy that it does.

Greg

Do you have a range of addresses excluded from the DHCP server?

from 10 to 250 are all allowed. 101 (the one i was using) was within the range. The fact that two other devices on the same network had no issue seeing the shares is what baffles me. 

Hi Greg, many network clients will locally cache DNS entries that they've read; so it can depend on the last time the device was 'bounced', hence different behaviour.

If you had any reference in the PC to the DNS name of that NAS, or any reference to any DNS name which DHCP allocated to that IP address, then the network address resolution on that PC could potentially become confused each time DHCP reallocates addresses.  If DHCP is configured correctly then this is unlikely to occur in the first place and will be definitely resolved on bouncing the PC, if DHCP isn't configured correctly then all bets are off.

If you are forced to use fixed IP addresses, then you must remove those addresses from the DHCP address pool; but much better just to use DHCP unless there's a really good reason to not do that.

Hi Huge, the behaviour (only one of 3 Windows devices having the issue with both NAS's) seems indeed consistent with a "caching" problem on this one Windows device, I will try today to apply the same (go from fixed to dynamic IP) on the Seagate NAS to see if this solves the problem there as well.

And the point about removing the fixed IP addresses from the pool is valid, I used to have it like that but when checking today I realized this wasn't the case anymore, I must have been careless at some point when re configuring the router.

thanks, Greg

back to square one: after working for a mere day I am having the same issue - apparently one day on the corporate network changes some settings which windows security does not like. There are a lot of posts on the net about this issue, no conclusive fix. At this point I am able to log on the NAS (putty / telnet) and even transfer files in drag and drop mode using the Winscp utility but still unable to mount the NAS as a Windows drive, which means when downloading or ripping I first have to store locally and then transfer to the NAS using winscp or ftp - really annoying....

I suspect then it's due to group policies set by your company.  Circumventing these may well be a disciplinary offence.

The best thing you can do is contact your tech support people to see if they can allow you this access.

Hi all, I edit this post just in case someone else faces a similar problem in the future: after quite some time without success I run today into a suggestion on the Netgear community forum which did the trick for me:

[Win 10 pro] Control panel -> Programs -> Turn Windows features on or off -> edit the "SMB 1.0/CIFS File sharing  support" parameter settings.

This parameter is indeed mentioned on several posts with the remark that it should be "on"; the tricky part is that in my case it was already "on" but what solved the problem (and it was this particular post recommending this seemingly moronic fix) was to set it to "off", reboot and then set again to "on" and reboot again. 

This seems to be it - although I have no clue why - WIndows works in mysterious ways.

Greg

I got caught out by this a few weeks ago so apologies for not replying earlier but this is the first time I saw this thread. After the recent Wannacry scare several security websites suggested blocking the insecure SMBv1 protocol, much like this

http://www.zdnet.com/article/w...cure-smbv1-protocol/

After doing so, I had the same problem as you had. Unfortunately, some NAS devices still use SMBv1, my buffalo NAS being one of them. The article also mentions that SONOS still use SMBv1 so it's not just NAS drives. It's worth knowing about even if it hasn't affected you as one day SMBv1 may get switched off in a microsoft update.

Thanks Redmires, very useful. Sounds like we should be expecting a firmware to address it soon (at least from QNAP in my case). Huge was right as he focused on SMB1/2 on one of his posts above...