Windows Cannot Access \\PCNAME — Error Code 0x80070043 (Fix)

What This Error Means

Windows shows this when you open a shared folder:

Windows cannot access \\PCNAME\ShareName

Error code: 0x80070043
The network name cannot be found.

Despite how it reads, this is good news: the other computer answered you.

0x80070043 comes from the other machine, not from your own. It is the SMB server's way of saying "I am here — I just do not have a share by that name." For you to see this error at all, four things have already worked: the name resolved to an address, your PC connected to it, the two machines agreed on an SMB version, and your credentials were accepted. Only the very last step failed.

That is what separates it from the error it is most often confused with:

• 0x80070035 — the network path was not found. Windows could not reach the machine at all.
• 0x80070043 — the network name cannot be found. Windows reached the machine; the machine has no such share.

So do not start with firewalls, network profiles or SMB settings. Those all stop you reaching the machine, and they produce 0x80070035 instead. Here, the machine is already talking to you. The share name is the thing to look at.

(One exception, and only on a company domain: if you are going through a DFS namespace and every target behind it is offline, that can surface as this error too. On a normal office network where you connect straight to a PC or NAS by name or IP, the rule above holds.)

Start Here — List the Real Share Names

Do this first. It takes ten seconds and, for most people, it is the fix.

In File Explorer's address bar, type just the computer name with no share name after it:

\\PCNAME

You get one of three results, and each one sends you somewhere different:

1. You see a list of folders. The machine is fine and sharing works. The share you were trying to open simply is not on that list under that name — carry on to Cause 1 below. Note the names you can see; one of them is probably what you actually want.

2. You get "the network path was not found" (0x80070035). You are on the wrong page — you cannot reach the machine at all. Go to error 0x80070035 — the network path was not found, which covers name resolution, firewalls and network profiles.

3. You get a password prompt you cannot get past, or "access is denied". The machine is reachable and the share may well exist — this is a permissions problem, not a missing share. See access denied — error 0x80070005.

One important limit: this list never shows hidden shares. Any share whose name ends in $ (like Backup$ or C$) is deliberately invisible here. If the share you want is hidden, its absence from this list proves nothing — skip to Cause 5.

If you hit this while mapping a drive from a script or Command Prompt rather than in File Explorer, the identical failure is reported as system error 67 — the network name cannot be found, which covers the net use syntax around it.

Cause 1 — The Share Was Renamed, Deleted, or Never Existed

This is the most common cause by a wide margin. The share name in your path does not match any share on the host.

Get the definitive list from the host machine. On the computer holding the files, open Command Prompt and run:

net share

Or in PowerShell:

Get-SmbShare | Select-Object Name, Path

Either one prints every share and the folder it points to. Compare that against exactly what you typed. Things that trip people up:

• The share name is not the folder name. A folder called Project Files may be shared as Projects, or the other way round. Windows only cares about the share name.
• A typo or a plural. \\PC\Project will not open a share named Projects.
• A trailing space or a lookalike character in the share name — rare, but it makes a name that looks identical fail every time. Retype it by hand rather than copying it.
• It was a different machine all along. Easy to do when two PCs have similar names.

The fix is either to use the correct name from that list, or — if the share really is gone — to re-share the folder on the host: right-click the folder → Properties → Sharing → Advanced Sharing → tick "Share this folder", and set the share name to what everyone expects.

Cause 2 — A Mapped Drive or Shortcut Still Points at the Old Share

If the error appears on a drive letter, at logon, or when you click a pinned shortcut — rather than when you type a path — the share was probably renamed or removed while a mapping still points at the old name. Windows keeps trying the stale target forever.

Fix the mapping rather than the share. In Command Prompt:

net use

That lists every mapped drive and its target. Remove the broken one and remap it to the correct name:

net use Z: /delete
net use Z: \\PCNAME\CorrectShareName /persistent:yes

Also clear out stale Quick Access pins and desktop shortcuts pointing at the old path — they will keep producing the same error long after the drive is fixed.

Cause 3 — The Share Exists but Its Folder or Drive Does Not

This is the one that defeats people who have already checked the share name twice, and almost no guide mentions it.

A share is just a registry entry pointing at a folder path. If the folder disappears, the share entry stays behind. net share still lists it, the host's owner insists the share is right there — and every client gets 0x80070043, because the server cannot serve a path that is not there.

It happens when:

• The shared folder lived on an external USB drive that is unplugged, asleep, or came back with a different drive letter.
• The share pointed at a second internal disk that failed, or was reformatted.
• On a NAS: an expansion volume did not mount, or the array is degraded/rebuilding.

How to confirm it in one step: run net share on the host and look at the path column, not just the name. Then try to open that exact path locally on the host itself. If the folder does not open on the host, no client will ever reach it.

The fix: restore the drive letter to what it was (Disk Management → right-click the volume → Change Drive Letter and Paths), reconnect the disk, or re-create the share pointing at wherever the folder lives now.

Cause 4 — The Host Has No Shares at All

If \\PCNAME opened but showed an empty list, the machine is serving SMB perfectly well and simply has nothing shared. Every share name you try will return 0x80070043, because none exist.

Usually this follows a Windows reinstall, a machine rebuild, or a "cleanup" that removed shares nobody realised were in use. The fix is to share the folder again on the host, as in Cause 1.

Note the distinction from a machine that is not serving SMB at all: that one refuses the connection outright and gives you 0x80070035, not this error.

Cause 5 — Hidden, Administrative, and NAS Shares

Hidden shares end in $ and never appear when you browse \\PCNAME. That is their entire purpose. You must type the full path — \\PCNAME\Backup$ — and it will work if the name is right. Not seeing it in the list is not evidence that it is missing.

Administrative shares (C$, D$, ADMIN$) are a common source of confusion, so be precise about which error you get:

• "Access is denied" → the share exists, you simply lack administrator rights on that machine. Normal, and not this error.
• 0x80070043 → the administrative share genuinely is not there. Some hardening scripts, Group Policy templates, and the AutoShareWks registry value disable them outright.

NAS boxes and routers with USB storage deserve their own mention. Firmware updates rename default shares (Public becomes public, home becomes homes) and occasionally reset SMB settings entirely. If a NAS share stopped working right after a firmware update, open its web interface and read the share list there — do not trust the name you have been using for two years.

If You Could Not List the Shares — You Have a Different Error

If typing \\PCNAME did not produce a folder list, stop working through the causes above; none of them apply. You have a reachability problem, and these are the checks that confirm it:

Test-NetConnection -ComputerName PCNAME -Port 445

TcpTestSucceeded : False means nothing is listening for SMB — the host is off, blocked by a firewall, or its Server service is stopped. Check that service on the host:

Get-Service LanmanServer

Also worth knowing: if the name fails but the raw IP address works (\\192.168.1.50 opens, \\PCNAME does not), that is a name-resolution problem rather than a share problem, and using the IP is a perfectly good workaround.

The full write-up for all of this is error 0x80070035 — the network path was not found. For why this layer of Windows is so fragile in the first place, see what the SMB protocol is and why it keeps breaking on Windows 11.

Why This Keeps Coming Back

Fixing the share name fixes today's failure. It does not stop the next one, because the whole model depends on every machine agreeing about names that any user can change at any time. Someone renames a folder, a USB drive comes back as E: instead of D:, a NAS firmware update relabels a share — and a path that worked for two years breaks with no warning and a cryptic code.

If you look after several machines, working through the Windows networking checklist for small offices once will catch most of the settings behind these errors before they bite. And if your office keeps adding PCs to the same share, how many PCs can realistically share files on one local network is worth reading before you blame any single machine.

The structural fix is to stop depending on share names at all. Oxolan does not use SMB for PC-to-PC transfers — machines find each other on their own channel and files move over a TLS 1.3 connection with certificate pinning, so there is no share name for Windows to resolve and nothing to break when someone renames a folder. It runs on Windows and macOS, with no usernames or passwords to manage.

Related Guides

• Error 0x80070035 — the network path was not found
• System error 67 — the same error from net use
• Access denied — error 0x80070005
• Error 0x80004005 — unspecified error
• Computers not showing up in the network (Windows 11)
• Network discovery on Windows, explained
• LAN file sharing: the complete guide