Problem Connecting To Shared Network Drive

Problem: Mapped shared network folder would intermittently disconnect itself, and user could not remap it.  When trying to remap it, user would get one of the following errors messages:

“Local device name is already in use”

“The drive could not be mapped because no network was found”

“The [\\Server Name\Folder] is not accessible. You might not have permission to use this network resource.”

Rebooting would fix the issue temporarily, but the disconnect would reoccur within an hour or so.

His colleagues did not have this problem, nor did the user have problems getting to other servers, the Internet, email application. He could ping the server by name, but could not map to the shared folder, by name or IP.

Microsoft’s KB890413 says the following:

This issue may occur if you log on to the Windows XP-based client by using a different connection type than you use to connect to the file server. If you created the network drive through a local area network (LAN) with your current user credentials, the mapping information does not contain any user information. When you log on to the computer, the operating system establishes only a partial connection to the share, and the network drive is considered used. Later, when you access the network drive, the connection is fully restored.

If you use another connection type such as Remote Access Service (RAS) to connect to the file server, the logon credentials used are different from the credentials that you used to create the network mapping. When you try to access the network drive to restore the connection, the operating system tries to use the logon credentials of the RAS connection. If the file share server does not accept the logon credentials of the RAS connection, the operating system cannot access the share. Then, the operation system tries to re-create the mapping to the already-used network drive, and the error occurs.

And their solution to this problem is to remove the existing network mapping and to remap the network drive. This did not work in my case, instead resulting in the error messages mentioned above.

I thought it might be the Symantec Protection Agent that was installed, so I uninstalled that, but the problem persisted. Tried putting the user on another switch port and VLAN (thus different subnet/IP), but that did not help either. The Windows Firewall was not being used.

I tried mapping the drive with my credentials, but I had trouble as well. I tried mapping by IP, no worky. I deleted all temporary files, cookies, and made sure there were no saved passwords under his profile (check that in Control Panel –> User Accounts, Advanced tab –> Manage Passwords):

The problem persisted. I then remoted into my desktop from the user’s laptop, and had the user map to the network drive using his credentials. That worked! So the problem was definitely with his laptop, and not an authorization/account issue.

I was about to rebuild a laptop for the user when I thought I should check one more thing.

Solution: I checked the local host file (C:\Windows\system32\drivers\etc\hosts) on the user’s laptop and he had an entry for the server name pointing to an old IP address. Even though the IP address listed was alive (it was being used by another server), which is why I was able to ping it, as soon as I removed the entry and pinged the server by name, it came back with a totally different IP address. Tried mapping to the shared folder again, and it worked!

I don’t know why the user had entries in his host file, but he’s an application developer, so that partially answers the question 🙂 .

Note: User’s machine running Windows XP Professional w/ Service Pack 3