Can't access server/shares on Win 10 machine

  • Not a new problem, but just can't get it to work ... been trying for hours ... head hurts from banging against wall ... need help.


    Problem: Dreaded Error code: 0x80070035 (network path was not found ...) on Win 10 machine.


    I can ...

    • ... see the server under network, but can't access and get the error.
    • ... access from another Win 10 machine just fine - read/write with no problems (same network, both connected via LAN).
    • ... ping the device's IP.
    • ... access the GUI just fine (have been doing the entire install that way).


    I have ...

    • ... tried the fix from this video (
      Externer Inhalt www.youtube.com
      Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
      Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.
      ), as well as
    • ... implemented the first 10 fixes from this list (https://thegeekpage.com/fix-wi…e_all_Windows_credentials)
    • ... looked through several threads here and tried a few "new things"

    One of the last things I tired (from Windows shares / samba Trouble shooting) was to change the lanmanworkstation behavior (via sc.exe in cmd) and believe to have set it to smb10 (while turning off smb20 - thereby disabling the "workstation" service). This only changed the error to "[NAME] is not accessible. (...) The network is not present or started" ... admittedly making it worse. So I undid it again (via regedit).


    At this point I have changed so many settings, I am worried I am breaking way more than I am fixing ... ;(


    The ONE thing that DID WORK, was turning on SMB v1.0 (which everyone seems to advise against) in "windows Feature" ... but with that enabled my VPN (NordVPN) refuses to connect - so not really a solution.


    I am dizzy from all the changes I made (and a tad worried I made things worse in the process) ... and I am VERY open to suggestions ...

  • ***update: I managed to retrace (most of) my steps and undo most changes ... putting me back @ square one - but that's still better than where I was a few hours ago.


    I also found the [HOW-TO] Connect to OMV SMB shares with Windows 10 and Microsoft Servers document and executed it step by step. I am happy to report that after completion, I was at least able to create a shortcut pointing to the IP address - allowing me to (finally) access the files from my main machine. (thank you crashtest) :thumbup:


    (still happy to hear if anyone ever found a "full solution to the issue - it's odd that one of my machine has no problem, while the other one refuses to play ball ...) ?(

    • Offizieller Beitrag

    This topic can go down the proverbial "rabbit hole" so all I can offer are a few more suggestions and things to look at.

    For a test, you can set a network share's permissions to the following:
    - Shared Folder. Users - Read/Write/Execute & Others - Read/Write/Execute. (DO NOT use ACL's. ACL's are the boxes at the top. None of those boxes should be checked.)

    - SMB share. Guests Allowed.

    These two items (above) will open up access to everyone on the local LAN. The permissions doc (following) explains client access to a server and can be used to tighten up the share, later, if needed.

    Workstation / user logon permissions for access to an OMV server. -> Permissions Doc.
    _____________________________________________________________________________

    Another thing to look at, real close, is the workstation firewall. If you have a second party firewall, it can easily block local LAN traffic if it's set to high security . You might try a test with your firewall temporarily turned off.

    Finally (this is a long shot) your router might be involved, particularly if one of your workstations is a laptop using a wireless connection. Some consumer routers have stricter security policies for wireless connections when compared to wired connections.
    _____________________________________________________________________________

    it's odd that one of my machine has no problem, while the other one refuses to play ball ...) ?(

    Not really. I'll go out on the limb and guess that we're talking about OEM versions of Windows, that came with PC's when they were purchased.

    The first problem with OEM's, "Windows Partners", is they attempt to model the typical uses of consumer PC's. Outside of business environments, client server architectures or even peer to peer LAN's are fairly rare. The largest number of consumer use cases tend to be E-mail and Web browser Internet access so OEM's tend to tighten security for consumer PC's accordingly. (And they all do it differently.) The Windows registry (regedit.exe) or the Local Group Policy Editor (gpedit.msc) allows OEM's to "help" users by hard pinning security settings and policies in ways that are difficult to find. Then there's the add-on's that OEM's may ship with these machines, third party security app's, firewalls, etc. Finally there are security app's that users add and delete themselves. In many cases, security app's change or add registry settings and/or security policy settings that are not reversed when they're uninstalled by Windows.

    Along these lines, rebuilding Windows using your existing product key might clear up some of the security barriers created by OEM's and security app's. (Make sure you have all of the hardware drivers needed before starting.) I'll acknowledge that this is not an easy route.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!