Member Avatar for Siberian

I'm experiencing a networking problem which I asked elsewhere and so this is the problem and this was the solution I was given, unfortunately the solution doesn't work in Windows10.

The problem was non-existant six months ago, which is a latop and a desktop both running Windows10. As of the last few weeks I cannot connect to a shared folder which lives on the desktop from the laptop. When I attempt to connect to the shared folder from the laptop I'm prompt for the login and pass, and I've tried all the login and passwords which I have and nothing is connecting ?

And so this is the solution which hasn't worked.

Method 1: I suggest you to run the shared folder troubleshooter as below and check if it helps.
Press Windows key +X, select Control panel.
Change the view by option on the top right to Large icons.
Click on troubleshooting and click on the view all option on the left panel.
Method 2: I suggest you to follow the below steps to change the settings.
Go to your hard drive and right-click the folder that's causing all the trouble.
Click Properties.
Click the Security tab
Then click Advanced
You'll see a window with some usernames. Now click Owner in the tabs above.
Click Edit, then select the username you wish to be able to open the folder and be sure to check the box that says "Replace owner on subcontainers and objects" then hit Apply.

A pop up will come up that says something like 'You have replaced the ownership for the selected folders' or something in that manner.

  • 3 Contributors
  • 6 Replies
  • 306 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by Siberian

Dani AI

Generated

Brief recap and checklist tied to the thread: the desktop still lists the share but remote access fails and re-creating the share made access worse (as noted by and ). ’s direction to verify the host’s share view was a good start. The most common causes in this scenario are: SMB protocol mismatch (SMBv1 vs SMB2/3), host-side services or share ACL vs NTFS ACL conflicts, Windows firewall blocking SMB ports, cached/wrong credentials on the client, or router/AP client‑isolation that prevents peer-to-peer LAN access. SMBv1 is deprecated and has security implications; prefer SMB2/3 where possible. (learn.microsoft.com)

Quick, high-value diagnostics to run (elevated PowerShell on the desktop and client to collect facts):

Get-SmbShare
Get-SmbServerConfiguration | Select EnableSMB1Protocol,EnableSMB2Protocol
Get-SmbSession
Test-NetConnection -ComputerName <desktop-ip-or-name> -Port 445
Get-Service LanmanServer,LanmanWorkstation

These show configured shares, which SMB dialects the host supports, any active SMB sessions, whether TCP/445 is reachable, and whether the Server/Workstation services are running. Use the SmbShare docs and the Test-NetConnection guidance for details. (learn.microsoft.com)

Permission and firewall notes (practical): share permissions and NTFS permissions are separate—confirm both grant the intended account explicit access (use the Advanced → Effective Access view to inspect actual effective rights). The Windows Defender Firewall commonly blocks SMB (TCP 445 / NetBIOS 139) or the File & Printer Sharing rule group; enable those inbound rules for the Private profile when testing, or temporarily disable the firewall for a short test window (restore it immediately afterward). Microsoft docs explain which rules/ports to allow. (learn.microsoft.com)

Credential and network-edge checks: stale or mismatched cached credentials frequently cause repeated auth prompts—inspect/remove them with Credential Manager or cmdkey, and clear any mapped sessions (net use * /delete). If both machines are on Wi‑Fi, confirm the router/SSID is not using “client/AP isolation” or a guest SSID that blocks client‑to‑client traffic (many vendors enable this by default on guest networks). If problems persist after these checks, a short local test account on the host (granting share+NTFS access) isolates credential/workgroup issues. (support.microsoft.com)

Practical order to follow: confirm the share exists locally, verify Server/Workstation services, test TCP/445 connectivity, check/enable firewall File & Printer Sharing rules (Private profile only), clear cached credentials and mapped sessions, verify SMB protocol support, and finally confirm router/AP settings. This sequence narrows the root cause quickly and avoids repeating share recreation steps that can change ACL inheritance and make troubleshooting harder.

Recommended Answers

All 6 Replies

Member Avatar for rubberman

I would try dropping the share, reboot, and reestablish the share. Also, when you try to log in again from the laptop, make sure the displayed workgroup is correct. If not, then use workgroupname\username instead of just the user name.

Member Avatar for Siberian

Reestablishing the share has now caused none of the computers to have access to the shard folder, rather then just one, arghh.

Member Avatar for CimmerianX

Lets start with this, from a command prompt run 'net share' and past the out here.

In that list you should see the share the is offered to all laptops.

From the same machine, try mapping a drive to \127.0.0.1\<sharename> and see if it works. Post the results if you get an error.

From a laptop, can you browse the shares on the machine? \<machinename> This should show you all non-hidden shares on the target host. IF that fails you can also try \<ip address> and get results. Let me know if that works/fails.

When you attempt to connect to a share, what error are you getting on the laptop side? Timeout, auth error, etc?

Member Avatar for Siberian

From the same machine, try mapping a drive to \127.0.0.1\<sharename> and see if it works. Post the results if you get an error.

Are you saying I should literally enter the IP 127.0.0.1\<sharename>; Or the the IPv4 Address IP ?

When I use the IPv4 address IP along with the share name as in XXX.XXX.X.XX\<sharename> I get an error; the request could not find host ?

Edited by Siberian
Member Avatar for CimmerianX

127.0.0.1 is the localhost. From the Machine with the share, if you use \127.0.0.1\ by itself, you should see all non-hidden shares on the host. If there are no shares listed, then definately no other machines on network will see shares.

Using a cmd prompt 'net share' will list all shares including the hidden ones.

IF no shares appear, then you should double check that the drives are actually shared.

Can the main host browse the network?

Member Avatar for Siberian

Shares do appear, including the shared folder; but 127.0.0.1 or \127.0.0.1 is returned as a;
'\127.0.0.1\' is not recognized as an internal or external command,
operable program or batch file.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.