Win11 cannot connect to Synology NAS and reports that the network path cannot be found. There are four pitfalls.
My cousin's second-hand Qunhui has been used for half a year and has been fine. Last month, he updated his laptop to Windows 11 24H2, and the next day he typed in the address bar \\192.168.0.30 , a pop-up window will directly report the error "Network path not found". His first reaction was that the NAS was broken, and he was about to come to my house with the machine in his arms, but I stopped him - if the web background could be opened, the NAS was functioning well, and the root cause of the problem was probably Windows.
Take a minute to figure it out first: The Internet is down, but SMB still doesn’t recognize it.
Don’t rush to mess with settings, run a command first: ping 192.168.0.30 . If it works, it means that the path between the computer and the NAS is good. The problem lies in the "file sharing language" of SMB. ; It doesn't work. That's a matter of the network layer. It has nothing to do with the four pitfalls I'm going to talk about in this article. First check whether the WiFi connection is correct or not. Have you turned on AP isolation? .
The copywriting of the error report itself is a clue. I stepped on it and got the right number.:
| Error message | High probability direction |
|---|---|
| Network path not found (0x80070035) | SMB negotiation was rejected or the service was not started. |
| You may not have permission to use network resources | The old NAS only recognized SMB1, and the system disabled SMB1. |
| Extension error/Unable to access shared folder | Signature negotiation fails, high incidence in 24H2 |
| Login failed (system error 86 or 1326) | The account password is incorrect, it's probably old credentials cached |
There is another one that goes against common sense: If the web page background can be opened, it does not mean that the SMB service is running. Web pages use ports such as 5000 and 5001, while file sharing uses ports 445, which are two different things. Feiniu looks at the SMB switch in the file service of the control panel. Synology looks at the control panel, file service, SMB, confirms that the service is "enabled" and then checks further. Not sure whether 445 is enabled or not, SSH into the NAS and type a message netstat -tln | grep 445 , if there is output, you are listening. ; Or on Windows telnet 192.168.0.30 445 , if it can be connected, it will work.
By the way, don’t rely entirely on credentials when reporting “login failed”. Even if the account and password are correct but you still can't get in, then it's really a permissions issue - go to the NAS backend to see if this account can read and write to that shared folder. The one where I divided accounts among the whole family The permission matrix inside is worth checking. My old man couldn't connect to his directory, and finally found out that I had left his account in the read-only group.
The most unfair trip: Win11 24H2 makes three changes to security
Why did my cousin’s phone just crash after the update? I looked through his error log to figure it out. Starting from Win11 24H2 and Server 2025, Microsoft has forced SMB signing by default, disabled guest credential fallback by default, and SMB1 continues to be dead. All three cuts hit the key points of the old firmware - his Synology was still running the old firmware of DSM6, and it couldn't keep up with the new rules when shaking hands. Windows directly refused to talk about it. On the surface, it was an ineffective prompt like "Cannot find network path."
If you want to confirm which step you died at, don't guess. There are ready-made ones in the event viewer.: Application and service logs, Microsoft, Windows, SMBClient, Security, follow the time points to find rejection records, and the reasons are clearly written. I locked it when I saw "Signature negotiation failed" on my cousin's machine.
There are two ways to solve it. I suggest you give priority to the NAS side.:
| path | operate | Suitable for whom |
|---|---|---|
| Right path: NAS side keeps up | Synology DSM7: Control Panel, File Services, SMB, Advanced Settings, server signature changed to "Client Defined"」 ; Feiniu upgrades to a new version of firmware. Samba can keep up, so there is no need to change it. | NAS firmware is not too old |
| fast road: Windows side unbinding | Administrator PowerShell run Set-SmbClientConfiguration -RequireSecuritySignature $false | The NAS is too old and cannot be upgraded. |
My cousin's DSM6 couldn't be upgraded, so I gave him the fast path. The home version does not have a Group Policy Editor, just use PowerShell and the effect will be the same. ; Get it after changing Get-SmbClientConfiguration Reading back, the RequireSecuritySignature column becomes False before it takes effect. To be fair here: The signature is resistant to tampering by middlemen. Turning it off means that file transmission will not be authenticated. Risks in a home intranet are controllable, but if you are worried, upgrading the NAS to firmware that supports signatures is the fundamental solution. Don't run naked for a long time. Microsoft has been tightening SMB in the past two years in order to block Relay attacks in the enterprise environment. It is purely a fool's errand to hit the home scene, but the trend is there, NAS firmware can be upgraded as much as possible.
The old NAS only recognized SMB1 error reports, which looked like this
Another type of older machine only has a feature in the error text.: 「You may not have permission to use network resources." The prompt looks like a permissions issue. In fact, it is probably because the NAS only supports SMB1, and Windows has disabled SMB1 by default starting from Win10 1709, and even negotiation cannot reach the permissions step.
If you really need help, you can turn SMB1 back manually.: Control Panel, Programs and Features, enable or disable Windows features, and check "SMB 1.0/CIFS file sharing support". But I don’t recommend leaving it on for a long time – back then, the WannaCry ransomware used the Eternal Blue vulnerability of SMB1 to knock on doors. NAS is targeted by ransomware virus This account has been written in , port 445 exposes the old protocol, which is equivalent to leaving the door open for ransomware.
A cleaner approach is to adjust the minimum SMB protocol version on the NAS side to SMB2 or above.: Synology has a minimum SMB protocol column in the SMB advanced settings, and Feiniu’s Samba configuration is the same. If the old machine really can't be adjusted, then the only two options left are "replace with new firmware" or "this machine only stores data that doesn't matter."
Password and name, the two most inconspicuous pitfalls
The first is credential caching. I bumped into it once on my cousin's machine: The NAS password is obviously changed correctly, but Windows keeps reporting login failure. The root cause of the problem is that the Windows Credential Manager stores old passwords from three months ago, and it takes it upon itself to try the old passwords every time it connects. Control Panel, User Accounts, Credential Manager, Windows Credentials, just delete the entry for that NAS and reconnect. Also flip through the "General Credentials" column. Some software stores the address there. The command line party can be used net use Look at the existing connections, net use * /delete Clean it up and then net use Z: \\192.168.0.30\media /user:admin Manual mapping, one step at a time. This manual mapping is giving Computer file backup It's best to run through it first. Time Machine and File History both point to this channel. If the channel is blocked, the backup will be idle.
There is an unpopular error in this area of credentials.: System error 1219, prompting "A user is not allowed to use more than one user name to connect to a server or shared resource multiple times." This means that for the same NAS, if you first use account A to mount the mapped disk, and then want to use account B to connect directly, Windows will not work. The solution is the one above net use * /delete , disconnect all old connections before trying again, don't fight with it.
The second is the difference between "name" and "IP". Many people are used to knocking \\mynas For this kind of machine name, if the router is changed or the network segment is changed, the name resolution will be interrupted, but the direct IP connection will still be available. When troubleshooting, always use IP first. If the name cannot be connected but the IP can be connected, it is a matter of mDNS or NetBIOS resolution. It does not affect the use. Changing the mapping from name to IP can be done once and for all. By the way, the IP of NAS is the best Bind it statically in the router , DHCP changed the address when the lease expired, and the whole family mapping disk all lost contact. I experienced it once.
The third pitfall is that "passwordless sharing" suddenly fails to connect. Some old NAS or guest shares opened to save trouble will be directly rejected on 24H2 - guest credential fallback is disabled by default. The fast way is also to run the administrator PowerShell Set-SmbClientConfiguration -EnableInsecureGuestLogons $true . But I recommend setting a serious account and password for sharing. Microsoft has made it clear that the guest path will only become tighter and tighter in the future. Instead of loosening it every day, it is better to pair it once.
If you still can't figure it out after arranging it all, just check these three things.
After arranging the four pits, there are still a few that are blocked. Check them in order.: The first is whether the device and the NAS are really on the same network segment. It is easy to configure the machine with IP manually. Planted on the fence of the gateway , ipconfig will make it clear at a glance. ; The second is whether the router has a VLAN or guest network to separate the two sides. The one about me building a wall in my house I wrote about the doorway of isolation. The two separated areas cannot find each other. ; Third, port 445 on Windows is occupied by other software. If you install some network disk clients, it will grab port 445. Stop the service and try again.
| Troubleshooting actions | command/location | Explanation in case of incomprehension |
|---|---|---|
| 1. Ping the IP of the NAS | ping 192.168.0.30 | Network disconnection, check connection and isolation |
| 2. IP direct connection sharing | \\ 192.168.0.30 | name resolution problem |
| 3. Change the correct credentials | Credential Manager deletes old entries | Old password cache |
| 4. Check signature and guest switch | Get-SmbClientConfiguration | Three swords in 24H2 |
| 5. Check the SMB protocol version | SMB advanced settings for NAS | Old machine stuck on SMB1 |
In the end, just one sentence: First, ping to distinguish the network and protocol, and then look for directions from the error message. 90% of the "sudden connection failure" after the Win11 update falls on the signature, guest, and SMB1. The rest is a small account of passwords and analysis. My cousin's station has been processed through the second method, and the mapping disk has not been lost again for three months now.
