Most likely you are correct -- there is some Windows related problem. That said, the Synology NAS units that are on the same network(s) do not exhibit this problem. More importantly, on the rare occasion that we need Synology technical support it is readily available and at very modest cost. Quite frankly I do not care whose problem it is, I just want it fixed.
We make widgets and occasionally have to deal with some technology and related problems. We have offices across the nation that use these systems. These offices also have heating systems and telephone systems. Our expectation is that they work and that we can find local vendors that will fix/upgrade/refurbish those systems when they break.
In the 1980s it was necessary to have specialized technology folks for networking and computer installation. Forty years latter my expectation is that this type of specialized support is no longer required. Think about your automobile -- you just use it. The notion that you should understand all of the interdependence and technical issues with that vehicle went away in the 1950s -- about 40 years after the mass market adoption in the early 1930s.
You hit on the critical issue -- finding specialized consultants who can deal with NETGEAR related problems. We have found none and that is to be expected since the product is no longer sold or supported. The economics are in favor of discarding the obsolete merchandise and replacing with more modern merchandise that can be configured and managed with a reasonable GUI interface.
If I am correct, you simply haven't seen the problem on the Synology connections because you've not (yet?) done the same thing on them that Windows simply does not allow. And if I'm correct, there is an easy fix. But I need the information I'm asking for to know I am correct and give you precise instructions on how to fix it.
I believe the problem is related to your drive mappings. If I am correct and you do them the same way on the Synology, you will experience the same issue. But if you do them differently (do what I am trying to help you change), then you will not.
Due to lack of support, you most likely were going to eventually need to retire the ReadyNAS. Feel free to use this as your excuse.
We did not need to wait for several days to determine the results.
Took the new Synology test system, installed drives, set up storage pools, etc. Let it do 'long' format of two RAID 1 volumes.
Established several directories for testing.
Windows recognized the device with a FileManager browse approach without any error messages. I was able to map network drives from any of our workstations to the directories that were set up.
The READYNAS system is still on the same network and throws the same error ...
"Windows cannot access \\READYNAS"
"Check the spelling of the name"
None of the workstations on the network can access the READYNAS system -- same error message.
My former characterization was that the READYNAS has contaminated the network -- at least it is not available to any workstations with the FileManager browse process.
I certainly do not understand the underlying issue but this approach gets us back to making and selling widgets.
No idea what you mean by "contaminated". They are not bringing down the network or interfering with access generally.
What clearly has happened is that the ReadyNAS hostnames aren't being resolved by the PCs. We don't know why that is happening, but with more effort we could maybe sort it out. But since you are ok just taking them out of service, we could just stop now.
As an aside - do you have a backup plan in place for the Synologies? You could potentially repurpose the ReadyNAS as backup devices. The PC issue you ran into won't prevent their use for Synology->ReadyNAS backups.
"Contaminated" was my term -- meant to refer to the fact that workstations that used to work properly all started to fail with trying to access the ReadyNAS with the FileManager browse and mapped drives. This is definitely impacting system performance and file access from the existing workstations. Possibly incorrect terminology but seemed to capture the essence of the issue.
You are correct, the ReadyNAS systems could be used for backup except Rsynch does not work as an exposed application in the Synology system. They have their own approach entitled "Active Backup for Business". I have Rysync working from the ReadyNAS system as a 'pull' service. It does work but it is clearly a work around.
That said, here is the list of my priorities...
System capability that integrates with our software and processes -- make and sell widgets
Systems that can be maintained by others in various locations -- availability of skilled personnel
GUI for management -- helps average non technical folks to maintenance and understand the system
Product life with a future
The unfortunate fact is that the Netgear systems fails on four out of the four criteria listed.
As far as I am concerned this thread should close -- no actual resolution but an interesting discussion that others may be interested in.
Did you map all the drives using a combination of the IP address and network name, as you did on the ReadyNAS? (I expect not.) What credentials do you use in the mappings? Did they all use the same one? Are they the same as the user's Windows credentials? We never got to the point of figuring out what you've done for the ReadyNAS since you declined to do the steps that would have let us know.. I still don't believe you have a problem with the ReadyNAS. What you most likely have is a Windows problem created over time as you (probably not even aware of it) used different ID's and credentials for those mappings. Without you clearing the mappings and trying to connect without any Windows limitations possibly interfering, which you did not do, it's impossible to tell. Having started from scratch in the Synology, you've probably been more consistent and avoided the Windows limitations.
To answer Sandshark's last post and possibly help others...
Yes, I used the identical process to map the network drives to the Synology units as was used to map drives to the ReadyNAS units. No IP address, just system names and associated share/directory names. The configurations established years ago and have been static.
The credentials used were identical for all operations -- a Windows 11 account that used FileManager browse function and then mapped drive letters. No special credentials or any different credentials were used to my knowledge since the NAS accepted the login process once the NAS credentials were entered in the Windows challenge screen. After the initial workstation connection nobody changes anything -- stuff just works.
The ReadyNAS is still currently on the same network with unique name and IP address but not accessible from ANY of the attached workstations with a FileManagement browse. Synology NAS devices easily accessed with Windows tools. I do not care about the 'why' of the problem, just the fact of the problem. It all started to occur after the most recent Windows 11 update from all attached workstations.
The most difficult was to move the data from the Netgear to the Synology devices. If anyone is interested they can PM me for the details.
By all management measures the ReadyNAS device just stopped working unless specialized IP mapping processes were used in FileManagement connection. This approach is not acceptable for average users who only are concerned with making and selling widgets.
The information you provided before differs from what you say you did on the Synology. You showed a mix of IP address and name (I'm assuming TROUT-NAS is at 192.168.0.232 since you never provided that information).
We never got to the point of finding out whether or not you used all the same credentials with the ReadyNAS. What you did on the Synology is very much what I was going to try to get you to do on the ReadyNAS -- replacing your old mix.
