Why does my "hosts" file entry have no effect when accessing network shares?

Question

I added the following line to a Windows7 hosts file:

127.0.0.1 mecserver

Using ping mecserver works fine, but if I use this name to connect to the notebook (like localhost) to see the Windows shares it always wants me to enter user credentials. Entering the local username + password doesn't work. Which indicates to me that the remote host is connected.

Using the following in the Windows explorer address field of local system results in:

\\mecserver Result: I have to enter a username and password but the local user don't work

\\localhost Result: Displays me the local shares - this is what I want with \\mecserver

\\127.0.0.1 Result: Displays me the local shares - this is what I want with \\mecserver

I want to use \\mecserver with the result of localhost/127.0.0.1. Is this somehow possible?

EDIT: What I have done so far:

I shared on a Notebook a network share with the name "testshare". Without any network cable/wlan connected I try to connect to this share from this notebook. This works with \localhost\testshare and \127.0.0.1\testshare. But I need a special path for a third party program like \mecserver\testshare. So I added the line 127.0.0.1 mecserver to the host file. ping mecserver works (local from this notebook) but when I try to access the testshare with \mecserver\testshare it promts a login window. I entered the current notebook user but it says password wrong. I even added a new testuser with the name test and password test and tried to add this into this login window but it don't work (password wrong). Enabling the guest account don't help either. The share is open to everyone and the file/directory security access for this folder/files too.

Adding 127.0.0.1 mecserver to the lmhosts file has the same effect like adding to the hosts file - it promts me this login window. I removed the 127.0.0.1 mecserver line from the hosts file when I played with the lmhosts file just to be sure.

Answer 1

I think you need to look at the LMHOSTS file. The hosts file seems to only affect generic DNS lookups. When you use the \\ to access a network share, WINS is used.

In the same folder where you find the hosts file, there should also be a lmhosts file.

The contents sound promising:

# This is a sample LMHOSTS file used by the Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to computernames
# (NetBIOS) names.  Each entry should be kept on an individual line.
# The IP address should be placed in the first column followed by the
# corresponding computername. The address and the computername
# should be separated by at least one space or tab. The "#" character
# is generally used to denote the start of a comment (see the exceptions
# below).

There is also a Wikipedia article on LMHOSTS.

---

Also, please note this section in the Advanced TCP/IP settings for your given network connection:

I would assume the checkbox has to be checked for the lmhosts file to be respected. Also, if editing the lmhosts file directly does not yield the desired result, I would attempt using that "Import LMHOSTS" functionality.

---

Update I'm confident that, in general, this is the right approach to the issue. If I create a copy of the lmhosts.sam file and add a new line at the end:

127.0.0.1 mecserver

I then have to use the "Import LMHOSTS..." functionality (which creates the lmhosts file). I can then browse to \\mecserver and am asked for credentials (like you describe). Without the change in lmhosts I had gotten an error telling me the machine is non-existent.

I can't shake the feeling that this manipulation has a negative impact on the general authentication process of Windows, because, as you describe, no otherwise valid login works on the presented prompt. However, this might be a new problem, which should be asked in a new question.

Answer 2

This is a permissions issue. The user that you are trying to use to access the share is not allowed to access the share. You need to add /mecserver/yourusername to the allowed users list for the share. Maybe it could also work if you check the "Everyone" entry in the users list when you create the share.