Forum Discussion
Can't access NAS by its name in the network after 6.10 upgrade
Before the 6.10 upgrade I was able to access all our shares simply by accessing \\NAS01. After the update, none of our Windows PCs was able to open the location, receiveing a Windows Explorer error s...
Sandshark wrote:
But when all machines are Win10, it does nothing.
Not too surprising - but I am wondering if it would help when the SMB 1.0 client (and possibly also the server) are enabled on the Win10 PC.
Funny reading here .... we talk of ReadyNAS OS 6.10 here, correct?
By default - and without the Legacy Discovery enabled - these systems make use of WSD - WS-Discovery. Permitting the Windows 10 system is configured to be in a private network (not a public network - this will close down almost all firewall rules) these Multicast device annoucements (and the related name resolution!) will pass through. If not - the problme is unlikley on the Windows 10 or the ReadyNAS side - much more some crappy network devices (consumer router switches, switches, powerline brdges, wireless bridges, wireless acess points are blocking this multicast traffic.
With the Legacy Discovery enablend, ReadyNAS OS 6 will bring up (aside of WSD) the NetBIOS host annoucement and will participate in the NetBIOS name resolution protocols. Considering there is a lot - some right, many wrong - information in the Internet, let's keep it on the fact that this does make use of IPv4 boradcast. Again, of the NAS and/or computers are not correct configured (especially on static configured devices, where subnet masks might be wrong), and permitting that no network devices (list as above with WSD) does block or limit these broadcasts to heavily, alos these will go through. For operating the ReadyNAS with Windows 10, this Legacy Discovery is not required.
With just WS-Discovery, and the Windows 10 feature SMB 1.0/CIFS Client enabled, both systems (WSD and NetBIOS) will take part in the name resolution - no need for a DNS infrastructure. For example ping NASname or ftp NASname will work.
A good indication is Windows Explorer - all WSD announed hosts _must_ show up here, as well the NetBIOS ones (SMB 1.0/CIFS Client feature enabled), and no crappy Internet Security garbage (yes!) blocking things, no network devi es blocking Multicast res. IPv4 boradcasts, you will see something like this:
There is one constraint: With higher resource usage on the WIndows system, you might have to force a reload of the list if there are many.
schumaku The main topi wasn't actually about discovery, I am able to see the NAS in the network from Win7 and Win10 without any problems. All Win10 PCs have the SMB1.0 client installed for backward compatibility and I also set the legacy discovery on the NAS. I run a DNS on Windows Server and have A and PTR records pointing to the NASs IP. Everything is good.
The problem arose while trying to access shares, I could see the NAS but couldn't access it until I added credentials manually in Windows. This didn't happen prior to the 6.10 update.
schumaku wrote:
the problme is unlikley on the Windows 10 or the ReadyNAS side - much more some crappy network devices (consumer router switches, switches, powerline brdges, wireless bridges, wireless acess points are blocking this multicast traffic.
I hear you. But my own network is set up to pass multicast and broadcast traffic. And I have one Windows 10 laptop that doesn't discover my RN526x (while other Windows 10 systems do).
The NAS is connected to an XS708ev2 (10 gigabit), which then connects to my main switch - a GS728TPv2. It's routed by an Orbi (and generally the laptop is connected to the Orbi WiFi). But the laptop does discover other devices, so it seems unlikely that the 239.255.255.250:3702 traffic is being blocked.
Fully with you! Not sure what is causing this ... older Windows versions (and earlier Windows 10 builds) automatically used the desktop login credentials and passed these to the standalone SMB file servers on access. With some changes on the Windows side - and I suspect it depends on how the local user account was created - this is no longer the case, this "nice" Windows for Workgroup single-sign-on (as it worked for decades (!!) - stopped to be workable. And we're back to this f**g Credentials Manager - which is updated in some semi-automatic ways for a while. And yes, there is some more obscurity when one does rename a NAS ...
Having the same problem.
After 6.10 it will not connect to it's name after working successfully for a good 5 years. It doesn't appear to be an SMB encryption setting because this still works.
Works from any station:
\\192.168.x.150\Videos
This does not work from anywhere regardless of OS:
\\dswatnas\Videos
I was sure it was an upgrade bug. Have you tried changing the name from dswatnas to dswatnas1 and see if you can access it?
JUST about to come back here and report that I did exactly that.
Renamed it to dswatnas01 and restarted SMB....clients can connect now.
I'm gonna try to change it back.
Well, changing it back, broke it again. :-(
We're in the exact same situation. I had to manually add credentials to each PC in order ot be able to access the nas by its original name.
Even when I add credentials is does nothing for me...it will not find the old name on the network. I'm just gonna change it and leave it, I don't have time for this. HA!
Getting the identical issue...suddenly none of my PC users can access the local drive. I'm not a network guy, so not clear how to go about resolving.
EKroboter wrote:This problem was resolved several weeks ago after rebuilind and reinstalling the whole setup. I've bigger problems now with AD unfortunately.
In an Active Directory environment, member servers are registered in the local DNS, so permitting the client name resolution is set correct, the NASname must be DNS resolveable.
In any case, the ReadyNAS are announced by a NetBIOS host announcement _and_ per WS-Discovery. If these information is not becoming visible, the clients lack of the Windows 10 CIFS/SMB 1.0 Client support (for the NEtBIOS part), and/or the network isn't correctly configired for IP brodcast (NetBIOS) and Multicast (WS-Dicovery).
Again and again always the same problems ... unlikley a REadyNAS 6.10.1 or whatever curent build issue.
DNS is fully accesible and working, not a single device has problems resolving internal host names.
The ReadyNAS has a static DNS entry registered when it joins the domain.
NetBIOS is fully functional. CIFS is also enabled in both our DCs.
I have two other Linux-based systems integrated into AD. None of them have issues. If by some reason (and this is expected), the DCs become offline, they will report an error but never, NEVER, delete user credentials and corrupt everything like the ReadyNAS did in two different opportunities. Our OpenFire server for intenal chat also syncs with AD for user credentials and has never done something like this.
So if DNS is fully workable, why should the NAS not being workable using the hostname?
Similar, with NetBIOS and WS-Discovery fully workable, there is no reason that the NAS isn't discovered and not show up in Explorer.
So for discovery, it's double fail safe, for name resolution, there are three independent systems ....it's hard to imagine that none of these all is working.
I was referring to our current AD issues, not this. The NAS always showed up in Explorer. The user credentials is what keeps getting f**cked everytime I try AD integration.
My problem (and most I've seen in the forum) has never been discovery, at least as far as I can tell. The NAS icon is sitting right there in "Network", ready to be double-clicked. But it's when it's double-clicked that the problems begin -- I am denied access, with Windows saying the NAS can't be found. Why putting the IP in the HOSTS file solves this is something I don't even understand, as that should be for a discovery issue. But it works.
When a PC with this problem is freshly booted, the first attempt at accessing the NAS takes a very long time, eventally coming back saying I can't access it. After that, the response is nearly instantaneous. What it is trying, but failing, to do during that long pause is unknown to me, but likely a key in all this.
Note that I refuse to put my NAS credentials in the credentials manager and give viruses and ransomware an easier path to get to it. But it should not be necessary that I do so. It should ask me for credentials, as it does when the IP is in the Hosts file and sporatically on other PCs after a fresh reboot.
If it matters, my user ID on the computers and NAS are the same, but my passwords are not.
I'm willing to bet that if you renamed the NAS in the interface, it will fix it, as it did for me.
I'm also pretty certain that something changed in the 6.10 release. I posted above and won't bug you with describing it again, but I got tired of it and just settled on the rename.
I have yet to apply the latest update it is saying I need 6.10.1
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
