Re: Can't access NAS by its name in the network after 6.10 upgrade

EKroboter · ‎2019-04-28

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 stating that the network location could not be found, or no permission existed.

Replacing NAS01 with the IP address worked without problems, so it wasn't a newtork or SMB issue.

What I discovered was that if I changed the NAS's name to say, NAS02, it would reappear on the network and everyone was able to access it. No login promtps or error. I changed it back as I have tons of shortcuts everywhere on the network pointing to the old name.

All our NAS accounts are local, but they match those from everyone's domain account on their PCs. This allowed us to access the NAS without any login prompt whatsoever.

After endlessly trying to figure out the problem, I added a Windows credential through Credential Manager in Control Panel with the \\NAS01\username nomenclature and I was able to instantly access the NAS with the old, original name.

I'm instructing all our users to do the same and add their credentials, but this does not really answer my initial concern: Why was I able to access the NAS by changing its name without having to create credentials in the first place, but had to create one to access it with the old name? Is there some sort of caching in Windows (or the NAS itself) that got corrupted after the upgrade?

I never had to create credentials before, or having to login to the NAS from Windows Explorer for that matter. Since the NAS local accounts match the Windows login credentials, there was no need to. Everything worked as if it were SSO.

StephenB · ‎2019-04-28

Did the NAS IP address change after you rebooted to install the upgrade?

EKroboter · ‎2019-04-28

No, the IP is static and hasn’t changed.

StephenB · ‎2019-04-28

If the IP address is static, then it can't be caching (since the cached hostname would still be correct).

It isn't clear to me why changing the credential made a difference. If you still have PCs that can't access the NAS, perhaps try rebooting them instead, and see if that works.

EKroboter · ‎2019-04-28

It isn't clear to my either, which is why I posted it here. I never had to manually add credentials, but for some reason I had to this time. The weird thing is I didn't need to add credentials when I changed the NASs hostname.

I'll report back tomorrow morning after everyone boots up their PCs at the office. If I get a ton of calls and IMs it means it didn't work and everyone will have to manually enter their login details.

Sandshark · ‎2019-04-28

You are not the only one that has suffered from their NAS not being accessable by name in precisely the manner you describe. I added the IP address to the HOSTS file to "solve" it. I have mentioned this many times here in the forum, and all I get are responses about things I have checked long ago.

StephenB · ‎2019-04-29

@Sandshark wrote:

You are not the only one that has suffered from their NAS not being accessable by name in precisely the manner you describe. ... I have mentioned this many times here in the forum, and all I get are responses about things I have checked long ago.

Agreed. Discovery is hit-or-miss in all the ReadyNAS I've owned (4.1.x, 4.2.x, and 6.x.x) using both Windows 7 and Windows 10. Often experimentation seems to cure it, but I think it's more of an accidental side effect. FWIW, I've found similar problems posted for other NAS and linux systems.

There is an "Legacy Windows Discovery" checkbox in the web ui (system->settings->services->SMB) that you could also try (particularly if you are using older versions of Windows). It might not help, but shouldn't do any harm.

@Sandshark wrote:

I added the IP address to the HOSTS file to "solve" it.

This will of course work, but doesn't scale well if you have lots of PCs that need access.

EKroboter · ‎2019-04-29

Alright, so I got a couple of messages this morning regarding this, so it was a widespread problem. No one was able to access the NAS until they added their credentials manually. I do have the Legacy Discovery feature enabled (it's not that NAS doesn't appear in the newtork, it does everytime), and I have created an entry in DNS pointing to the NAS IP. Now, here's another funny thing: I created a second DNS entry simply called "nas". I was able to instantly access all shares, no credentials needed by typing \\nas\share-name\

There's seems to be an issue with the original hostname somewhere, but I cannot seem to figure out where.

Sandshark · ‎2019-04-29

"Legacy discovery" works great when I also have my dual-boot system running Win7, I assume because that machine becomes the NetBIOS master browser. But when all machines are Win10, it does nothing.

If the HOSTS file addition hadn't "fixed" it, I suppose I could keep a Win7 VM running.

FWIW, it is hit-or-miss. I currently have one computer on which I did not change the HOSTS file (I just use IP address) finding the NAS by name, my security system PC. My HTPC is not finding it. I can't tell if either of my desktop computers can, because I did edit the HOSTS file on them. My secondary desktop, the one that can dual boot, is in Win10, so Win7's not a factor. And my laptop (also Win7) is off (as usual).

StephenB · ‎2019-04-30

@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.

schumaku · ‎2019-04-30

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.

EKroboter · ‎2019-04-30

@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.

StephenB · ‎2019-04-30

@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.

schumaku · ‎2019-04-30

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 ...

dswhat · ‎2019-05-01

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

EKroboter · ‎2019-05-01

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?

dswhat · ‎2019-05-01

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.

dswhat · ‎2019-05-01

Well, changing it back, broke it again. 😞

EKroboter · ‎2019-05-01

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.

dswhat · ‎2019-05-01

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!

allllan · ‎2019-06-24

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.

StephenB · ‎2019-06-25

@allllan wrote:

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.

Does entering \\nas-ip-address into the file explorer address bar give them the share list? Use the real IP address of course.

EKroboter · ‎2019-06-25

Hi @StephenB

This problem was resolved several weeks ago after rebuilind and reinstalling the whole setup. I've bigger problems now with AD unfortunately.

schumaku · ‎2019-06-25

@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.

EKroboter · ‎2019-06-25

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.