Windows 7 - Can't access UNC Shares but can Ping and RDP

Just went into Contrl Panel> Network & Sharing Center> Change Advance Sharing Settings> Clicked down pointing arrow (for the currently connected network type, e.g. Home or Work)> Turned Off Password Protected Sharing.

I know that this shouldn't have happened (isn't correct way). Because, Password protection is very important for networks. But there might be something and, for the time being, I'm able to browse my Local area network, not only just able to ping them or use internet.

I had a similar problem: I could not access 1 out of 6 servers through the fileexplorer. All servers were on the same network (an other network than what I was trying to access them from) and were fairly similar.

For 5 of the 6 I was promted with a username/password dialog, and I provided the correct credentials.

For the last one however, I was never promted. I only got the "windows can not access \server" alert. I had no problem accessing the server with RDP or ping.

What worked for me was going to the credential manager, and adding the credentials manually (here I could see the credentials I had previously added for the other servers).

This is an old discussion, but for anyone experiencing similar issues on more recent versions of windows, it may also be worth checking if it is the version of SMB employed by the server.

A simple test for this is to open a command prompt/powershell and resolve the UNC name for the server with nslookup UNCNAME. With the IP address provided, attempt to open the connection with start IPADDRESS, e.g. start 192.168.1.128.

If there is an SMB version issue, an error message similar to the following should result;

This command cannot be run due to the error: You can't connect to the file share because it's not secure. This share requires the obsolete SMB1 protocol, which is unsafe and could expose your system to attack. Your system requires SMB2 or higher. For more info on resolving this issue, see: https://go.microsoft.com/fwlink/?linkid=852747.

The Microsoft article referenced in the error explains the problem. Ideally, the server should support SMB2, but should you need to connect until this is resolved, this article at windowscentral.com explains the process for windows 10 users.

Steps listed as follows;

1. Open Control Panel.
2. Click on Programs.
3. Click on Turn Windows features on or off link.
4. Expand the SMB 1.0/CIFS File Sharing Support option.
5. Check the SMB 1.0/CIFS Client option.
6. Click the OK button.
7. Click the Restart now button.

Screenshots in the windowscentral article.

Now that your error code is finally correct try this:

In two words: Domain vs. Workgroup

Basically, here’s why it took an hour to figure this out: after using this file share SUCCESSFULLY for one Windows session thru address bar in Windows Explorer and subsequently mapping the drive and asking Windows to restore the network mapping on reboot, things got sour after the actual reboot. Typing share location in address bar would time out in 90 seconds. The error is beyond cryptic. I would know what to do if it said that IOINC Active Directory does not contain such-and-such user name. Instead it said unspecified error 0x80004005. Diagnostics could not determine anything either. After scratching my head, I went to disconnect the share, and try to re-establish it. Direct approach (typing \PCName\FileShare ) still led to the error code 0x80004005. Resolution was in sight, but still not obvious. Map network share dialog has a way to enter new credentials. Just re-tying password still took me to 0x80004005. I had to see DomainName\UserName as the fully-qualified user name to get what was going on. Windows 7 Pro assumed that UserName was a domain user, whereas it isn’t. BUG, N times over. Having supplied the new credentials, I can now type \PCName\FileShare in Windows Explorer address bar and see the files. I haven’t tried, but I guess clearing passwords in Internet Explorer Options would have resolved the issue as well.

Source: https://social.technet.microsoft.com/Forums/windows/en-US/c9f17816-9ef3-4249-98e6-5de990112d3d/windows-cannot-access-machinesharedfolder-error-code-0x80004005?forum=w7itpronetworking

We experienced this occurring on one specific folder only. Turns out Offline Folders caused the issue because we use redirected folders. So Windows is literally connecting to that share with the other users credentials as soon as Windows starts so it refuses the connection from the logged in user.

The solution used was to turn off offline sync.

Have you tried looking at the network adapter settings ControlPanel -> Network and Sharing -> then click on your adapter->properties button.

make sure Client for Microsoft Networks is installed and Ticked