Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Dmytro Koval
Error 0x80070035 is one message for four different failures between a share name and an open connection. This guide gives a one-line test for each cause, the fix order Microsoft recommends for the Windows 11 24H2 signing and guest changes, and the three fixes that close the ticket and open a bigger one.
A user double-clicks a mapped drive that worked on Friday and gets a dialog about checking the spelling of the name, with a hex code at the bottom and no clue which of a dozen things broke. The code is a catch-all for "the SMB client gave up before it reached the share", and the fix depends entirely on where it gave up. This guide reads error 0x80070035 the way the SMB client does, step by step, so the test you run first is the one that names the cause.
Windows reports 0x80070035, "The network path was not found", when its SMB client cannot turn \\server\share into an open connection to a share. That is one message for a chain of five steps: resolve the name to an address, open TCP port 445, negotiate an SMB dialect, authenticate, and connect to the share. A failure at any of the first four can surface as this code, which is why guides for it list everything from DNS to drivers.
The dialog is also misleading on purpose. Windows does not say "your NAS refused to sign" or "the name never resolved", because the client often cannot tell which happened from its side. What it can tell you is in two places: Test-NetConnection, which checks the first two steps, and the SMB client event log, which records the last two. Between them, the seven causes below sort themselves in minutes. If the share is new rather than broken, start with the walkthrough for mapping a network drive instead, because a path typed wrong produces the same code.
Each cause has a one-line test. Run them top to bottom and stop at the first one that fails.
| Cause | One-line test | What a failure looks like |
|---|---|---|
| Name resolution | ping nas then ping 192.168.1.20 | The IP answers, the name does not |
| 24H2 signing and guest changes | Event Viewer, SmbClient, Security | Event 31017, rejected insecure guest logon |
| SMB1-only device | Same log | Event 32000, SMB1 negotiate response received |
| Firewall on port 445 | Test-NetConnection nas -Port 445 | TcpTestSucceeded: False while ping works |
| Discovery off or Public profile | Get-NetConnectionProfile | NetworkCategory: Public |
| Credentials or Kerberos | net use \\nas\share /user:dom\name | Prompts, then fails with a logon error |
| Path or share gone | net view \\nas | The share is not in the list |
Name resolution comes first because it is the cheapest to test and the most common on a workgroup network. If \\192.168.1.20\share opens and \\nas\share does not, the problem is the name, not SMB. Microsoft announced in April 2022 that NetBIOS name resolution was moving to a "learning mode", used only after mDNS and LLMNR fail, with the goal of mDNS being the only multicast name protocol on by default. A NAS that only ever registered a NetBIOS name is the device that stops answering to it. The durable fix is a DNS record or a hosts entry, not the registry switch, though EnableNetbios under the Dnscache parameters key (1 allows it, 3 is learning mode) restores the old behavior on one machine while you add the record. When the name resolves to the wrong address or nothing at all, the DNS troubleshooting guide covers the resolver side.
The 24H2 changes come second because they are the reason this error spiked in 2024 and still fills Microsoft Q&A. Windows 11 24H2 Pro, Enterprise and Education require SMB signing on every connection, and 24H2 Pro no longer falls back to a guest logon when a server asks for one. Microsoft's own NAS advisory from June 2024 lists 0x80070035 as one of the errors a guest-only device now produces, and explains the reasoning in one line: "We don't know the difference between a NAS that doesn't have SMB signing enabled and an evil server that doesn't want SMB signing enabled." Signing cannot be used with guest credentials, so a NAS that offers both no signing and no password fails twice.
The r/msp thread above is the practitioner reaction when the advisory landed. One reply called it a nothing-burger because Samba has supported signing for years; another reported Windows 11 machines that had been failing to map an unauthenticated CentOS share for a year before the article explained why. The line that holds up is the last one: the support is fine, "its tolerance for devices that are running a substandard security configuration is not."
SMB1-only devices are third. Windows 11 has not contained the SMB1 client or server by default since its first release, per Microsoft's SMBv1 page, updated June 2025. A device that only speaks SMB1 cannot negotiate a dialect with it, and the client logs event 32000, "SMB1 negotiate response received from remote device when SMB1 cannot be negotiated by the local computer". Microsoft's listed messages for this case read differently from 0x80070035, so if you see "this share requires the obsolete SMB1 protocol", you already have the answer. The protocol history, and why SMB1 is the version that carried WannaCry, is in our SMB explainer.
The firewall is fourth. Test-NetConnection nas -Port 445 separates "I can reach the host" from "I can reach SMB". Ping succeeding while the TCP test fails means something between the two machines drops 445: a host firewall on the server, a client isolation setting on the Wi-Fi, or a VLAN rule. The Windows Firewall guide covers the inbound rule a Windows file server needs, and when ping itself fails you are in destination host unreachable territory rather than SMB.
Discovery and the network profile are fifth, and they only matter for browsing, not for a typed path. A client on a Public profile turns network discovery off, and with SMB1 gone the Computer Browser service went with it, so the Network node in Explorer depends on the Function Discovery Provider Host and Function Discovery Resource Publication services. Microsoft's guidance is to set both to Automatic (Delayed Start) if you still need Explorer to list machines, and to map drives instead where you can.
Credentials are sixth. On a domain, a cached password that changed, a machine account whose secure channel broke, or a Kerberos ticket for the wrong name all end in the same dialog. net use with an explicit user and the error it returns names the real cause, and a client that cannot reach a domain controller for a ticket fails here even though 445 is open. Seventh, and last because it is the one people check first, is the path itself: the share was renamed, removed, or never existed on that host, which net view settles in one line.
When event 31017 is in the log, Microsoft's advisory gives an order, from the option that keeps your data safe to the ones that do not. Enable SMB signing on the NAS. Disable guest access on the NAS. Give the NAS a username and password and use them. Update the firmware if the device cannot do any of those. Replace the device if the firmware cannot be updated. Only then come the Windows-side switches, and Microsoft's signing page, updated August 2025, is direct about them: "We don't recommend disabling SMB signing as a workaround for third-party servers. We also don't recommend trying to sign with guest accounts."
If you take the Windows-side route for a single legacy device, do it with the commands rather than the GUI, so the change is recorded and reversible:
powershellGet-SmbClientConfiguration | Format-List RequireSecuritySignature, EnableInsecureGuestLogons Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force Set-SmbClientConfiguration -RequireSecuritySignature $false -Force Get-SmbConnection | Format-Table ServerName, Dialect, Signed, Encrypted
The last line is the receipt. It shows the dialect each live connection negotiated and whether it is signed, which is how you confirm the NAS now signs after you turned it on, or that a client is talking to something unsigned when it should not be. Both switches have Group Policy equivalents, "Microsoft network client: Digitally sign communications (always)" under Security Options and "Enable insecure guest logons" under Lanman Workstation, and the guest one writes event 31018 every time it is used, so an audit can find the machines where somebody flipped it.
Three fixes close the ticket and open a bigger one. Re-enabling SMB1 is the first. It works, because SMB1 always allows guest fallback and cannot be stopped from doing so, which is exactly why Microsoft deprecated it in 2014 and strongly recommends against reinstalling it. A device that needs it is on the SMB1 product clearinghouse list, and the fix is firmware or replacement, not a Windows feature checkbox that stays checked for years.
Turning off signing fleet-wide is the second. One NAS in one office does not justify dropping relay-attack protection on every laptop the policy touches; scope the exception to the machines that use the device, and put a date on it. Turning the firewall off to test is the third. Test-NetConnection on port 445 tells you whether the firewall is the cause without lowering anything.
The thread above is the shape of the shotgun fix. The original poster enabled every SMB version and turned on discovery, rebooted, and reported it working "but I don't know exactly why". Replies kept arriving for years, and the ones from the 24H2 era point at Microsoft's advisory and skip straight to the guest and signing commands. Nobody in the thread ran a test first, which is why nobody knows which change fixed it.
One 0x80070035 is a ticket. Twenty on the Monday after a feature update is a 24H2 rollout meeting a NAS, and the useful question is which devices are talking to it and how. Get-SmbConnection on each client lists every live SMB session with its dialect and signing state, and the SmbClient Security log lists every rejected guest logon with the server name. A script that collects both across a client's devices answers the question in one run: which machines still reach an unsigned or guest-only share, and which ones have had the guest switch flipped by hand. If you run OpenFrame, that is a script run across a client's devices with the output collected, so the list of affected machines exists before the first user calls.
The same output drives the decision. A device that appears in the signed column after its firmware update is done. One that still negotiates SMB 1.x or keeps rejecting guest logons after the NAS settings changed needs the vendor, or a replacement with a date on it.
Error 0x80070035 means the SMB client stopped somewhere between the name and the share, and the dialog will not say where. Ping the IP, test port 445, and read the SmbClient Security log for 31017 or 32000 before you change a setting. On Windows 11 24H2 the usual answer is a NAS that does not sign or still relies on guest access, and the fix belongs on the NAS, not in a policy that lowers every client to meet it.
Next, if the share works by IP and the mapped drive still drops at sign-in, the network drive guide covers persistent mappings and the GPO that replaces them.
Head of Product Engineering
Hi! My name is Dmytro, but everyone calls me Dima. I’m a Software Developer and together with the development team, I help bring Flamingo to life — putting it on its feet from a technical perspective. Originally from Lviv, Ukraine 🇺🇦, but currently based in Spain, where I’ve been enjoying the blend of great weather, culture, and nature. I’m passionate about the mountains and love traveling — exploring new places and cultures really inspires me. These experiences constantly recharge me and give me a fresh perspective, both personally and professionally.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.