‘Network Path Not Found’ (0x80070035): The 5‑Minute Fix

February 25, 2026 • February 25, 2026 • Read: 20 min • Views: 1

Was this helpful?

It’s 9:07 a.m. Someone can’t open \\fileserver\finance. The CFO is on the call. You try it yourself and—boom—Windows throws
“Network Path Not Found” with 0x80070035. Not “access denied.” Not “wrong password.” Not even the courtesy of a clue.

This error is Windows’ way of saying, “I can’t get there from here.” That “there” might be DNS, routing, SMB, firewall rules, or a share
that doesn’t exist anymore because someone “tidied up” a storage cluster at 2 a.m. Let’s fix it in five minutes—most of the time—and
know exactly what to do when it’s not a five-minute problem.

Fast diagnosis playbook (check first, second, third)

When you see 0x80070035, do not start by rebooting things. Reboots are how you erase evidence and waste meetings.
Start by proving which layer is lying.

1) Is it name resolution or is it transport?

Try the IP: \\10.20.30.40\share. If IP works but hostname fails, it’s DNS/NetBIOS/hosts search order.
Test TCP 445: if 445 is blocked, SMB is dead on arrival. Fix firewall/routing, not “permissions.”

2) Is SMB reachable but the share missing?

List shares remotely (or at least hit \\server in Explorer). If the server responds but the share doesn’t, it’s a share name/path issue.
Check server-side SMB service: if the server isn’t offering SMB, Windows will report “path not found” with maximum confidence.

3) Is it authentication disguised as “not found”?

Some environments map auth failures, SMB signing mismatches, or policy blocks into generic errors.
Check the Windows event logs and the server’s SMB logs. If you can reach 445 but sessions fail, it’s auth/policy.

4) Scope the blast radius in 60 seconds

One user only? It’s local config, VPN split tunneling, or credential cache.
One subnet? It’s firewall segmentation or a routing ACL.
Everyone? It’s the server, the storage backing it, or a shared infrastructure dependency (DNS, AD, firewall policy push).

Paraphrased idea, attributed to Gene Kim (DevOps/operations author): High-performing ops teams reduce mean time to recovery by practicing and standardizing diagnosis.
The playbook above is your standardization.

What 0x80070035 actually means (and what it doesn’t)

0x80070035 is Windows returning ERROR_BAD_NETPATH. Translation: the client tried to reach a UNC path
and could not establish a valid network path. That can happen before credentials are even considered.

The trap is assuming it’s “a network thing” in the physical sense. It might be, but it’s often a name thing (DNS),
a policy thing (firewall rules, SMB hardening), or a service availability thing (SMB server stopped, NAS wedged).

What it usually is

DNS mis-resolution: hostname points to an old IP, wrong VLAN, or stale record.
TCP 445 blocked: “security improvement” that forgot file servers exist.
SMB server not listening: service down, NAS SMB disabled, or port not bound.
Share renamed/removed: path literally doesn’t exist anymore.
Client-side features off: SMB client disabled, network discovery policy, or a broken workstation stack.

What it usually is not

NTFS permissions (those typically give “Access is denied” or credential prompts).
A random Windows “glitch” that will be solved by “try again later.” Try again later is not a strategy.

The 5‑minute fix: the shortest path to the truth

Here’s the opinionated order of operations. Follow it. Deviate only with evidence.

Minute 1: Bypass name resolution

If \\fileserver\share fails, try \\IP\share. This is the fastest fork in the road.
If IP works, stop touching firewalls and start fixing DNS/name resolution.

Minute 2: Prove the network path exists (TCP 445)

SMB over modern Windows is TCP 445. If that port doesn’t connect, nothing else matters.
You can’t negotiate SMB over vibes.

Minute 3: Check if the server is offering SMB

If 445 is reachable but the share is “not found,” confirm the SMB service is running and the share exists.
If it’s a NAS, confirm it didn’t flip from SMB to “security-first: NFS only” after a firmware update.

Minute 4: Eliminate local client weirdness

Flush DNS cache, clear stale mapped drives, and verify the workstation is on the right network (VPN split tunneling is a repeat offender).

Minute 5: Check logs where the truth lives

On Windows: SMBClient Operational logs. On servers: SMBServer logs, security logs, and NAS audit logs. The error code in the log is usually more honest than Explorer.

Joke #1: SMB is like a vending machine—when it says “not found,” it usually means the snack is there, but the slot is jammed.

Practical tasks: commands, expected output, and the decision you make

Below are real tasks you can run. Each one includes: the command, typical output, what it means, and the decision you make next.
I’m using Windows commands; the prompt label is just a wrapper to satisfy the formatting rules. Run these in PowerShell or CMD.

Task 1: Confirm the hostname resolves to the right IP

cr0x@server:~$ nslookup fileserver.corp.example
Server:  dns01.corp.example
Address: 10.10.0.10

Name:    fileserver.corp.example
Address: 10.20.30.40

What it means: DNS resolves. Now verify that 10.20.30.40 is actually your file server and not a recycled IP.
If the IP is wrong, you’ve found your root cause.

Decision: If DNS is wrong, fix the A record, scavenging/stale records, or client DNS suffix search. Do not “work around” with hosts files unless you like future outages.

Task 2: Check what Windows thinks the name should resolve to

cr0x@server:~$ ping -4 fileserver
Pinging fileserver [10.20.30.40] with 32 bytes of data:
Reply from 10.20.30.40: bytes=32 time<1ms TTL=127

What it means: The client can resolve and reach the IP via ICMP. This does not prove SMB works, but it suggests routing is sane.

Decision: If ping fails but DNS resolves, test routing/VPN and local firewall. If ping works, move to port 445.

Task 3: Prove TCP 445 is reachable from the client

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection fileserver -Port 445 | Format-List ComputerName,RemoteAddress,TcpTestSucceeded"
ComputerName    : fileserver
RemoteAddress   : 10.20.30.40
TcpTestSucceeded: True

What it means: You can open a TCP connection to SMB. Firewalls and routing between client and server are probably fine.

Decision: If TcpTestSucceeded: False, stop. Fix firewall rules, segmentation ACLs, VPN policy, or the server listening state. Don’t touch share permissions yet.

Task 4: Validate you’re hitting the intended server (reverse lookup + ARP)

cr0x@server:~$ arp -a 10.20.30.40
Interface: 10.20.30.123 --- 0x11
  Internet Address      Physical Address      Type
  10.20.30.40           00-15-5d-4b-12-34     dynamic

What it means: You’re talking to a MAC on your L2 path. In weird networks, wrong IPs can be silently reassigned.

Decision: If the MAC isn’t what you expect (or it changes), investigate IP conflicts, mis-scoped DHCP, or a rogue VM clone.

Task 5: Try the UNC path by IP to bypass DNS entirely

cr0x@server:~$ powershell -NoProfile -Command "dir \\10.20.30.40\finance"
Get-ChildItem : Cannot find path '\\10.20.30.40\finance' because it does not exist.
At line:1 char:1
+ dir \\10.20.30.40\finance
+ ~~~~~~~~~~~~~~~~~~~~~~~~~

What it means: Network path to the host exists (if 445 is reachable), but the share name may not.
This is different from not being able to reach the server at all.

Decision: Confirm the share name (case-insensitivity isn’t your problem; spelling is). Verify on the server/NAS: share exists and is exported over SMB.

Task 6: Enumerate shares on a Windows file server

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare -CimSession fileserver | Select-Object Name,Path,Description"
Name     Path              Description
----     ----              -----------
finance  D:\Shares\Finance  Finance department share
public   D:\Shares\Public   General share

What it means: The share exists server-side, and you have rights to query it (or you ran as admin with proper credentials).

Decision: If the share isn’t listed, it’s not a client issue. Fix the server config, clustered role, or the underlying storage mount.

Task 7: Verify the SMB server service is running (Windows server-side)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service -Name LanmanServer | Select-Object Name,Status,StartType"
Name         Status  StartType
----         ------  ---------
LanmanServer Running Automatic

What it means: The server is offering SMB. If it’s stopped, Windows clients will often see “path not found” while flailing around.

Decision: If Status is Stopped, start it and investigate why it stopped (patching, dependency failure, security hardening).

Task 8: Confirm the server is listening on TCP 445

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 445 -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess"
LocalAddress LocalPort OwningProcess
------------ --------- ------------
0.0.0.0      445       4
::           445       4

What it means: Something (typically the System process) is listening on 445 on both IPv4 and IPv6.

Decision: If nothing is listening, fix the SMB server service, binding, or policy that disabled SMB.

Task 9: Check Windows Firewall rules relevant to SMB (client or server)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Select-Object DisplayName,Enabled,Profile | Format-Table -AutoSize"
DisplayName                                      Enabled Profile
-----------                                      ------- -------
File and Printer Sharing (SMB-In)                True    Domain
File and Printer Sharing (SMB-In)                False   Public
File and Printer Sharing (SMB-In)                False   Private

What it means: SMB inbound is allowed only on the Domain profile. If the server thinks it’s on Public, you’re blocked.

Decision: Fix the network profile classification or enable the correct rule profile. Don’t just “turn off firewall” unless you enjoy explaining yourself later.

Task 10: Confirm the client’s network profile (Domain vs Public)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Select-Object Name,NetworkCategory,IPv4Connectivity"
Name               NetworkCategory IPv4Connectivity
----               --------------- ----------------
CorpLAN            DomainAuthenticated Internet

What it means: The client believes it’s on a domain network. If it says Public, Windows will apply stricter firewall defaults and discovery behavior.

Decision: If it’s Public unexpectedly, investigate NLA (Network Location Awareness), VPN posture, and domain connectivity.

Task 11: Check if SMB client features are present and enabled

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol,SMB1Protocol-Client | Select-Object FeatureName,State"
FeatureName         State
-----------         -----
SMB1Protocol        Disabled
SMB1Protocol-Client Disabled

What it means: SMB1 is disabled, which is good. But if you’re talking to an ancient NAS that only speaks SMB1, this will break.

Decision: Prefer upgrading the NAS or enabling SMB2/3. Only enable SMB1 as a last resort, as a temporary containment measure, and behind strict network controls.

Task 12: Clear stale mapped drives and reconnect cleanly

cr0x@server:~$ net use
New connections will be remembered.

Status       Local     Remote                    Network
-------------------------------------------------------------------------------
OK           Z:        \\fileserver\finance       Microsoft Windows Network
The command completed successfully.

cr0x@server:~$ net use z: /delete
z: was deleted successfully.

cr0x@server:~$ net use z: \\fileserver\finance /persistent:no
The command completed successfully.

What it means: You’re forcing a fresh session setup. This helps when credentials, stale sessions, or dead mappings are involved.

Decision: If reconnect fails with System error 53, you’re still at network/name/port layers. If it fails with System error 5, you’re in permissions/auth land.

Task 13: Inspect DNS client cache for stale answers

cr0x@server:~$ ipconfig /displaydns | findstr /i fileserver
fileserver
    Record Name . . . . . : fileserver.corp.example
    Record Type . . . . . : 1
    Time To Live  . . . . : 120
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 10.20.30.40

What it means: The workstation cached an IP. If that cache is wrong, Windows will keep failing until TTL expires or you flush it.

Decision: If the cached IP is wrong, flush it and fix upstream DNS so the problem doesn’t boomerang.

Task 14: Flush DNS and retry

cr0x@server:~$ ipconfig /flushdns
Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

What it means: You removed cached DNS entries. If name resolution was stale, this can immediately fix the issue for that client.

Decision: If flushing fixes it, you still need to ask why DNS changed and why caches were stale (record updates, scavenging, multiple DNS servers).

Task 15: Verify Kerberos/DNS health from the client (domain environments)

cr0x@server:~$ klist
Current LogonId is 0:0x3e7

Cached Tickets: (2)
#0>     Client: user@CORP.EXAMPLE
        Server: krbtgt/CORP.EXAMPLE@CORP.EXAMPLE
        End Time: 2/5/2026 18:12:03
#1>     Client: user@CORP.EXAMPLE
        Server: cifs/fileserver.corp.example@CORP.EXAMPLE
        End Time: 2/5/2026 18:12:03

What it means: You have a CIFS service ticket for the file server. That usually indicates name resolution and domain auth are functioning.

Decision: If there is no cifs/ ticket and you’re repeatedly failing, investigate SPNs, time skew, or fallback to NTLM being blocked by policy.

Task 16: Check SMB client event logs for a more precise error

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-SMBClient/Operational' -MaxEvents 5 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-List"
TimeCreated      : 2/5/2026 9:09:41 AM
Id               : 30805
LevelDisplayName : Error
Message          : The SMB client failed to connect to the share. Error: The network path was not found.

What it means: The SMB client is confirming the failure. Often, nearby events include negotiation, signing, or auth details.

Decision: If you see negotiation errors or signing requirements, match client/server SMB policies. If you only see “path not found,” go back to name/port/service checks.

Task 17: On the server, confirm the share path exists on disk

cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'D:\Shares\Finance'"
True

What it means: The underlying directory exists. If this is False, the share can exist but point to nowhere (or the volume isn’t mounted).

Decision: If the path is missing, investigate storage: failed mount, iSCSI disconnect, cluster disk offline, DFS target broken, or a NAS volume unexported.

Task 18: Check DFS referrals when the “server” is actually DFS

cr0x@server:~$ powershell -NoProfile -Command "dfsutil /pktinfo"
PKT Entry: \\corp.example\dfs\finance
  Referrals:
    \\fs01.corp.example\finance  (ACTIVE)
    \\fs02.corp.example\finance  (INACTIVE)

What it means: DFS is in play. A broken target or referral can surface as “network path not found,” especially if clients are referred to an offline node.

Decision: Fix the DFS target health, disable the dead target, or correct site costing. Don’t blame “the network” when DFS is handing out bad directions.

Joke #2: “Network path not found” is Windows’ way of saying “I walked to the door, but the building is either gone or locked—good luck.”

Common mistakes: symptom → root cause → fix

This section is blunt because the same mistakes repeat in every company with a helpdesk ticket queue and a change window.

1) Symptom: Hostname fails, IP works

Root cause: DNS A record points to old server; stale cache; wrong DNS suffix; split-brain DNS between on-prem and VPN.
Fix: Correct DNS records (and scavenging), flush client cache, verify clients use the right DNS servers, and stop relying on NetBIOS broadcasts.

2) Symptom: Works on-office LAN, fails on VPN

Root cause: VPN split tunneling excludes file server subnets; VPN firewall blocks 445; DNS over VPN returns wrong view.
Fix: Route the file server subnet over VPN, allow TCP 445 to approved servers, and align DNS view with the access path.

3) Symptom: Suddenly fails for everyone after “security hardening”

Root cause: Group Policy disables SMB client, blocks NTLM, requires SMB signing, or turns off guest access; firewall policy changes block inbound SMB.
Fix: Roll back or adjust policy with a controlled exception list; validate SMB signing/NTLM settings on both ends; test with a pilot group.

4) Symptom: Only one share fails; others on same server work

Root cause: Share renamed, removed, or points to missing volume; DFS target broken; share-level permission removed.
Fix: Confirm share exists server-side, verify share path, restore volume mount, or correct DFS target/referral.

5) Symptom: Server reachable, but Explorer shows empty / long delay then error

Root cause: SMB negotiation stalls due to signing/encryption mismatch; antivirus/endpoint security intercepts SMB; network middleboxes mangling packets.
Fix: Check SMB client/server logs, temporarily bypass inspection for testing, validate SMB dialect support, and confirm MTU/fragmentation is sane.

6) Symptom: Old NAS unreachable after a Windows update

Root cause: NAS only supports SMB1; Windows update removed/disabled SMB1 client.
Fix: Upgrade NAS firmware/config to SMB2/3. If impossible, isolate that NAS and enable SMB1 client only for required machines temporarily.

7) Symptom: Intermittent “path not found,” especially in clustered storage

Root cause: SMB continuous availability not actually available; cluster failovers break sessions; backend storage hiccups unmount volumes.
Fix: Validate cluster roles and share settings, check storage multipath/iSCSI stability, and monitor failover events correlated with user reports.

Three corporate mini-stories (how this fails in real life)

Mini-story 1: The incident caused by a wrong assumption

A mid-sized company migrated their file server to a new VM. Same hostname, new IP, “no problem.” The team updated DNS and tested from
a couple of IT desktops. Everyone went home.

At 8:30 a.m., the helpdesk started seeing 0x80070035 across multiple departments. Not all of them. Just enough to cause panic.
The on-call engineer assumed “the new VM is down” and restarted the SMB service. No change. Then restarted the VM. Still no change.

The issue was painfully simple: two DNS servers. One got the updated A record. The other didn’t replicate correctly and kept serving the old IP.
Workstations were configured with both DNS servers, so resolution depended on which one answered first. The file server wasn’t down;
half the clients were being sent to a dead address.

The fix was to correct replication and force a zone transfer, then flush client caches. The lesson was more important than the fix:
“DNS updated” is not a statement. It’s a hypothesis that needs proof from multiple resolvers.

Mini-story 2: The optimization that backfired

Another organization had a “latency reduction” project. Someone noticed SMB traffic hairpinning through a central firewall when branch
offices accessed the HQ file cluster. The proposed solution: add a new firewall policy that blocked SMB from non-approved subnets and
force branches to use a local cache service.

The cache service rollout was delayed, but the firewall change went in on schedule because it was “safe”: after all, most SMB shouldn’t
be leaving HQ anyway. The change request even included a list of “allowed” subnets.

By noon, engineering could not access build artifacts on \\buildshare. Finance couldn’t access month-end spreadsheets. The error
wasn’t “blocked by policy.” It was 0x80070035. Windows clients don’t narrate your firewall changes; they just fail.

Root cause: the allowed list didn’t include a VPN address pool used by remote staff and a set of new Wi‑Fi VLANs. The “optimization” was
correct in spirit but rolled out in the wrong order and without an observability hook for denied 445 flows.

The fix wasn’t just adding subnets. They implemented staged rollouts with deny logging, dashboards keyed on TCP 445 blocks, and a canary
client in each major network segment. The moral: optimize last, after you can see what you’re breaking.

Mini-story 3: The boring but correct practice that saved the day

A large enterprise ran DFS namespaces for user shares with multiple targets per site. It wasn’t exciting. It wasn’t trendy. It was
consistent, documented, and tested quarterly. The storage team maintained a simple runbook: validate DFS referral health, validate SMB
listening, validate share paths, validate backend volumes.

One morning, a firmware bug on a storage array caused a subset of LUNs to momentarily drop. On two file servers, the volume hosting a
critical share came back with a different drive letter due to a mount-order change. The share still existed in the OS—but pointed to an
empty path. Clients got “network path not found” intermittently depending on which DFS target they were referred to.

The on-call engineer didn’t guess. They followed the runbook. First: Test-NetConnection 445 (good). Second: Get-SmbShare on both targets
(share exists). Third: Test-Path on the share path (false on two nodes). Fourth: fix the mount points and validate.

Outage time was limited because someone did the boring work earlier: consistent DFS target monitoring and a habit of checking share paths
against storage mounts. No heroics. No midnight Slack poetry. Just a system that fails in known ways and a team that recognizes the pattern.

Interesting facts and short history (SMB, Windows networking, and why we suffer)

Fact 1: SMB originated at IBM in the 1980s and was later adopted and extended by Microsoft; it’s older than many production “modernization” plans.
Fact 2: Windows networking historically relied on NetBIOS name resolution and broadcast behavior—convenient on flat LANs, messy in routed networks.
Fact 3: TCP 445 (“SMB over TCP”) reduced reliance on NetBIOS over TCP 139, but plenty of environments still carry legacy assumptions from the 139 era.
Fact 4: SMB1’s weaknesses became infamous enough that modern Windows disables SMB1 by default; this breaks older NAS devices in exactly the way you’d predict.
Fact 5: The same UNC path can traverse different stacks: direct SMB, DFS namespaces, or even WebDAV in some setups—each with distinct failure modes.
Fact 6: Windows Explorer errors often collapse multiple underlying failures into one generic message; the event logs are usually more specific.
Fact 7: SMB signing and encryption improve integrity/security but can cause negotiation failures when clients and servers have mismatched policies.
Fact 8: “Network Location Awareness” (NLA) influences firewall profiles; misclassification to Public can silently block file sharing traffic.
Fact 9: DFS referrals can change based on AD site/subnet mapping; wrong site mapping can send clients to distant or dead targets.

Checklists / step-by-step plan (for humans under pressure)

Checklist A: Single user reports 0x80070035

Have them try the IP path: \\10.20.30.40\share. If it works, it’s name resolution.
On the client: run Test-NetConnection server -Port 445. If it fails, it’s local network/VPN/policy.
Clear mappings: net use * /delete (careful) or remove the specific drive, then reconnect.
Flush DNS cache: ipconfig /flushdns.
Check profile: Get-NetConnectionProfile. If Public, fix network classification.
Pull SMBClient Operational log events around the failure time.

Checklist B: Entire team can’t access one share

Confirm the share exists server-side: Get-SmbShare or NAS share list.
Confirm the share path exists: Test-Path on the server; verify mount points/volumes.
Confirm SMB service and listening port on server: Get-Service LanmanServer, Get-NetTCPConnection -LocalPort 445.
Check firewall policy changes and denied logs for port 445.
If DFS: validate referrals and target health; disable dead targets.

Checklist C: “It worked yesterday” after patching or policy rollout

Check whether SMB1/guest/NTLM policies changed on clients or servers.
Validate SMB signing requirements match on both sides.
Check Windows Firewall rules under “File and Printer Sharing.”
Compare a working machine vs a failing machine: DNS servers, VPN posture, network category, and security agent versions.
Roll back the policy if you can’t prove the change is benign.

FAQ

Q1: Is 0x80070035 the same as “System error 53”?

They’re closely related. net use often reports connectivity/name/path problems as “System error 53 has occurred. The network path was not found.”
Explorer may show 0x80070035 for the same underlying failure class.

Q2: Why does using the IP sometimes work when the hostname fails?

Because you bypass DNS and any name-resolution layers (DNS suffix search, WINS/NetBIOS fallback, cached results). If IP works, your transport is fine.
Fix naming, not firewalls.

Q3: What port do I need open for SMB file shares?

Modern SMB is TCP 445. Legacy NetBIOS/SMB can involve 137–139, but you should be using 445 for supported Windows and NAS platforms.
If 445 is blocked, expect 0x80070035 or similar failures.

Q4: Can permissions cause 0x80070035?

Usually permissions issues show up as “Access denied,” credential prompts, or specific auth errors. But policy blocks (like “deny NTLM”)
can surface as generic failures. Check SMBClient logs and server security logs to be sure.

Q5: Why does it fail only from home or only on VPN?

VPN routing and firewall rules are the usual culprits. Split tunneling can exclude the file server subnet, and some VPN security profiles block 445 by default.
Confirm with Test-NetConnection -Port 445 from the client while on VPN.

Q6: Should I enable SMB1 to fix this quickly?

Only if you’ve confirmed the server/NAS supports only SMB1 and you cannot upgrade immediately. Enabling SMB1 expands your attack surface.
Treat it like a temporary bridge with containment, not a permanent solution.

Q7: What if ping works but SMB doesn’t?

Ping proves ICMP reachability, not application reachability. Firewalls often allow ICMP but block TCP 445. Or the SMB service isn’t running.
Test 445 explicitly and check server listening state.

Q8: What if 445 connects but the share still says “not found”?

Then you’re past routing/firewall and into SMB/share/DFS territory: wrong share name, share removed, share path missing, DFS referral broken,
or negotiation/policy mismatch that logs more detail than Explorer shows.

Q9: How do I know if DFS is involved?

If the path looks like \\domain\dfsroot\share, that’s DFS. Use dfsutil /pktinfo to see which target you were referred to.
A dead referral target can make the path look “not found.”

Q10: Why does Windows sometimes show different errors for the same issue?

Different components surface different abstractions: Explorer, SMB client, redirector, credential manager, and DFS each have their own error mapping.
Trust packet-level reality (can you connect to 445?) and event logs over GUI phrasing.

Conclusion: practical next steps

0x80070035 isn’t mystical. It’s a layer-cake failure: name resolution, connectivity to TCP 445, SMB service availability, share existence, and then auth/policy.
The fastest fix is the fastest disproof—try IP, test 445, validate the share exists, and read the logs that don’t sugarcoat.

Next steps you can take today:

Create a one-page runbook from the “Fast diagnosis playbook” and pin it where your on-call actually looks.
Monitor and alert on TCP 445 denies at network boundaries (with change correlation), not just server CPU graphs.
Inventory SMB versions on NAS/file servers; eliminate SMB1 dependencies before the next Windows hardening wave eliminates them for you.
For DFS environments: regularly validate referrals and remove dead targets. DFS is great until it’s politely directing users to nowhere.
Standardize a canary test from each network segment (LAN, VPN, Wi‑Fi VLANs) that checks name resolution and 445 connectivity to critical shares.