Unable to access shared folder using hostname

authenticationnetwork-sharepassword

I'm currently having issues accessing shared folders on a Windows Server.

The Architecture:

Flat standalone network with 2 Windows Servers (2008 R2 SP1) and 2 Windows Clients (Windows 7 SP1 64bit). All machines are configured with a static IP address, configured in a single workgroup (i.e. no DC). Each machine is configured with only one user (Administrator) and all have the same password.

The Problem:

Client 1 cannot access the shared folders on Server 1 using the hostname in the address. It can however access them if using the IP address of the machine. The error we are receiving is "The Specified network password is not correct" (the correct details are being used).

Client 1 can access shared folders on Server 2 without any problems. Client 2 and Server 2 can access the shared folders on Server 1 without any problems.

If we ping the hostname we get a valid response.

What's been Tried:

  • The times are in sync
  • GPO Setting – Network Security: LAN Manager Authentication Level is set at "Send LM & NTLM - use NTLMv2 session security if negotiated" system wide.
  • GPO Setting – Network access:Sharing and Security model for local accounts is set as "Classic" system wide.
  • Home Group is turned off on both Windows 7 Clients.
  • The Advanced Sharing Settings are set the same on Client 1 and Client 2.
  • The "Workstation" Service is set at automatic and has started.
  • The hosts file is correctly configured. There is no lmhosts file in %SystemRoot%\System32\drivers\etc folder, lmhosts.sam doesn't contain any records.
  • The credentials have been manually added to the windows credential manager with no effect.
  • A new user has been added to both Client 1 and Server 1, the problem does not change.
  • Manually mapping a network drive (including using different credentials) presents the same error.

Notes:

While yes a possible solution could be to use the IP address rather than the hostname, this isn't possible as the IP Addresses will be changed after we have completed works on the system.

Sorry for the War and Peace Question, thanks for any help you can give.

Best Answer

So, to sum up:

  1. Problems like this are frequently caused by inconsistent name resolution.
  2. When accessing file shares, try to use real host names as they are configured in the System Properties dialog, and not any kind of alias. If having troubles, try accessing the share by the IP address of the server. If still unsuccessful, you probably have a problem of a different kind and this instruction is not for you. If successful, start troubleshooting on the client as follows:
  3. Get rid of unneeded entries in the hosts and lmhosts files. If possible, don't use these files at all.
  4. If you are using DNS infrastructure, try nslookup <name-of-the-fileserver> (remember: use real host name and not an alias) and then nslookup <ip-address-returned-by-the-first-nslookup> - if the latter resolves to a different hostname, or if the former returned an incorrect IP address, this may be the cause of the problem. Troubleshoot your DNS zones - both forward and reverse. Also make sure that the DNS suffixes are the same across all of the hosts.
  5. If you have a workgroup setup not relying on DNS, nslookup won't help - try instead ping <name-of-the-fileserver> and ping -a <ip-address-of-the-fileserver> to check if name resolution works correctly in both directions. If there are anomalies troubleshoot your TCP/IP configuration: check for incorrectly assigned/duplicated IP addresses (including secondary IP addresses) both on the primary and any additional network adapters (including disconnected ones).
  6. The above steps may need to be completed from the server's perspective, too.
  7. Sometimes it is necessary to "pre-stage" user's credentials (that is, after configuring the user's credentials on the server but before trying to connect to it) in the client's Windows Credentials Manager by using the following format for the username: ServerName\UserAccountName (and not simply UserAccountName).
Related Topic