Picture the scene. Your NAS shows up green in its dashboard, the shared folder exists, and you type 192.168.1.50media into File Explorer only to get slapped with 0x80070035: The network path was not found. Nothing is broken, yet nothing works.
The first time I hit this on a client's Synology DS220+, I burned forty minutes assuming the drives had died. They were fine. The problem was a Windows security default that had quietly turned off the old SMB1 protocol the share still expected.
That is the frustrating part of this issue. The error text almost never points at the real cause, so you end up guessing. Below is the order I actually work through, fastest checks first, so you stop poking at random settings.
Start by confirming what is actually failing
Before changing anything, figure out whether the machine can even see the NAS. Open PowerShell and run a quick reachability test.
Type ping 192.168.1.50 using your NAS IP. If pings come back in single-digit milliseconds, the network layer is healthy and your problem is authentication or protocol, not wiring.
Next, test the SMB port directly with Test-NetConnection 192.168.1.50 -Port 445. A TcpTestSucceeded : True line means the SMB service is listening and reachable. If that comes back False but ping worked, a firewall or a stopped file-service is the culprit, and you can skip straight to the firewall section.
Fix the credentials Windows silently cached
Roughly half the tickets I see come down to stale saved credentials. Windows remembers the first username and password you ever used for that server and keeps replaying it, even after you change the NAS password.
Open Credential Manager from the Start menu, click Windows Credentials, and look under Generic Credentials for any entry starting with your NAS IP or name. Delete every one of them.
Now try the mount again. When the login box appears, type the username exactly as the NAS expects it. On many QNAP and Synology units that means just admin, but if your device is joined to a domain or you set up a specific SMB user, you may need NASNAMEusername format.
A mistake I see constantly: people type their Windows account password out of habit instead of the account they created on the NAS itself. Those are two separate systems with separate passwords.
Match the SMB protocol version
This is the one that eats the most time. Modern Windows 11 and Windows 10 builds ship with SMB1 disabled for good security reasons, since it is the protocol WannaCry rode in on. Older NAS firmware and cheap network drives sometimes only speak SMB1.
Check what your machine currently allows by running Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol in an administrator PowerShell.
The correct fix is almost never to re-enable SMB1. Instead, go into your NAS control panel and raise its minimum SMB version. On Synology that lives under Control Panel, File Services, SMB, Advanced Settings, where you set the maximum to SMB3 and minimum to SMB2. On QNAP it is under Network and File Services.
Check the Windows network profile
Windows treats Public and Private networks very differently. On a Public profile it blocks most inbound and outbound file-sharing traffic by design, which quietly kills SMB mounts.
Go to Settings, Network and Internet, click your active connection, and confirm the network profile type is set to Private. I have watched a laptop drop its share every single morning purely because a Windows update reset the profile back to Public.
While you are in there, verify that Network Discovery and File and Printer Sharing are switched on under Advanced sharing settings.
Confirm the SMB client features and firewall
On fresh Windows 11 installs the SMB Direct and client components are usually present, but corporate imaged machines sometimes have them stripped out. Open Turn Windows features on or off and confirm SMB 1.0/CIFS Client is unchecked (correct) while the core Client for Microsoft Networks is intact.
For the firewall, run Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" | Where Enabled -eq 'True'. If nothing returns, the sharing rules are disabled and no SMB traffic will pass regardless of everything else you fixed.
Re-enable them from the Windows Defender Firewall control panel under Allow an app through firewall, ticking File and Printer Sharing for the Private column.
A quick reference for common error codes
Here is the cheat sheet I keep pinned. Match the exact code Windows gives you to the likely cause before you start changing settings.
| Error code | Most likely cause | First thing to try |
|---|---|---|
| 0x80070035 | SMB version mismatch or discovery off | Raise NAS min SMB to SMB2, enable discovery |
| 0x800704cf | Network profile set to Public | Switch profile to Private |
| System error 53 | NAS not reachable on port 445 | Test-NetConnection to port 445 |
| 0x8007052E | Wrong username or password | Clear Credential Manager, retype NAS user |
| System error 1219 | Two sessions with different credentials | Run net use * /delete, then remount |
The two-session trap
System error 1219 deserves its own note because it confuses everyone. Windows refuses to hold two connections to the same server using different usernames at the same time.
If you mapped the share once as a guest and now try to remap it as admin, Windows blocks the second attempt. The fix is to drop all existing sessions first.
Run net use * /delete in PowerShell, confirm with Y, then map the drive again with the correct account. This clears the conflict in one shot roughly 90 percent of the time.
Mount it the reliable way
Once the underlying cause is cleared, skip the flaky Map Network Drive wizard and mount from the command line where the errors are readable.
Run net use Z: 192.168.1.50media /user:admin /persistent:yes and enter the password when prompted. If it returns The command completed successfully, open File Explorer and your Z: drive is live.
Doing it this way gives you a precise error code when something is still wrong, instead of the vague dialog box the GUI throws. For deeper protocol background, Microsoft and the SMB protocol overview on Wikipedia are worth a read, and Synology's own SMB access guide covers the NAS side settings clearly.
Where this usually lands
Nine times out of ten the real fix was one of three things: a cached credential Windows would not let go of, an SMB1-only expectation on old firmware, or a network profile that flipped to Public. Work them in that order and you rarely need the exotic stuff.
Save yourself the future headache by making the mount persistent and writing down the NAS username somewhere. The next time a Windows update resets your network profile, you will know exactly which two settings to check instead of losing another lunch break to it.
Frequently asked questions
Why does my NAS ping fine but the shared folder still won't open?
Ping only proves the network layer works, not that SMB is reachable. Run Test-NetConnection to port 445 to confirm the file service is listening. If that fails while ping succeeds, the cause is a firewall block or a stopped SMB service on the NAS.
Should I turn SMB1 back on to fix error 0x80070035?
No. SMB1 is unencrypted and was the protocol exploited by WannaCry. Instead, go into your NAS control panel and set the minimum SMB version to SMB2 and the maximum to SMB3. That keeps the connection secure while still letting Windows negotiate a supported version.
What causes System error 1219 when mapping a drive?
Windows will not hold two connections to the same server under different usernames at once. If you connected once as guest and then try again as admin, it blocks the second attempt. Run net use * /delete in PowerShell, confirm, then remap with the correct account.
Why does my mapped drive disappear every time I restart Windows?
The mount was not made persistent. Add /persistent:yes to your net use command, or tick Remember my credentials and Reconnect at sign-in in the mapping dialog. Without this, Windows drops the mount at every reboot even though the fix itself worked.
Do I use my Windows password or a separate one to log in to the NAS?
You use the account you created on the NAS itself, which is a completely separate system from your Windows login. Typing your Windows password out of habit is a very common reason mounts fail with error 0x8007052E. Check the exact username format your NAS expects, sometimes just admin, sometimes NASNAMEusername.
