SMB1 solution?

Blanker-2 thank you for the encouraging words! Many other community members silently disappear once they have got the solution (or not).

Have quickly re-read this thread. Honestly, I can't find any complex workarounds. Can you?

The ReadyNAS screenshots were taken on very early ReadyNAS OS 6 units from the first OS 6 hardware generation (a RN516) and the second generation OS 6 hardware (a 10 GbE enabled RN628X), an early two bay ARM based OS 6 Beta sample (similar to your RN312) unfortunatley died. Along with some tests for factory reset and recovery during the Beta period, we have not applied any config changes at the level shown. ReadyNAS OS 6 was always visible by the now legacy NetBIOS host announcements and name resolution, since some builds (I even have not recognized the change because I have the Windows 10 CIFS/SMB 1.0 Feature [inheriting the NetBIOS server resp. client support] enabled to retain compatibility with legacy NAS) the ReadyNAS are WS-Discovery (WSD) announced. I admit that these two ReadyNAS are on 6.9.4 Beta and RC for a longer time already. Overall - and believe me I would have complained - Netgear has done a good job with the ReadyNAS OS 6 systems when it came to the technical progress and Microsoft enforced changes of dropping SMB 1.0 and NetBIOS host announcement and name resolution starting from some point in the Windows 10 life cycle (annouced years ago!).

Most of your confusion must have triggered by other discussions, explanation, lot of many times false noise in the net. Being that these were caused by the SMB 1.0 vulnerabilities which existed on Windows and SAMBA (the Open Source implemented on most U**x based NAS and top of the line business storage systems), being by Microsoft implementing a little bit a complex way for the phase out (behavior depending on the system status being scratch installed or updated).

The most overseen detail is Windows 10 is asking when connecting to a network (WiFi or Ethernet) if the network connected to is open and public, or trusted and private. This makes Windows 10 behave different in firewall rules as well as in services active and workable on the network. Also some Windows OEMs who think it's a great idea not having the Windows File Sharing protocols enabled on the network interfaces (proof enough they don't understand Windows concepts). And sometimes it seems that Windows does silently decide to make a previously trusted network to a pubic one. Changing this is rather easy from Explorer, permitting one does know the NAS IP address - an access attempt by say \\192.168.1.234 does trigger a notification helping the user to change the network to a private, trusted one.

Last, the number of "bigger" oddities - I hope Sandshark does read this. In some very few occasions, users continue to have problems on some Windows system to discover the NAS properly (mostly networking issues, poor subnet configurations, or bad networking components blocking IP Multicast traffic). And the very few ones which can discover the NAS by name, and badly fail while attempting to establish the connection (potential cause can be a bigger corruption of the Windows system [sigh, I had one and never figured out - everything looked absolutely perfect - only a scratch re-installation cured], or by third party Internet Security and firewall [sorry:] garbage (because it does cause issues normal users can't overcome the problems).

Regards,

-Kurt

I have read it.  But you don't have all the information, which is in the thread I included a link to.  The NASes  are discovered just fine.  I just can't actually access them by name.

---

Blanker-2 wrote:
How do you access them then?

---

The other way is to access them by their IP address.