3

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.

Improve this question
9
  • Is the name by which you are trying to access Server 1 from Client 1 the same name that is configured in the system properties dialog on Server 1 or you are accessing Server 1 by a DNS alias, for example? If you use two distinct names, this may be the cause. Are DNS suffixes the same? Are reverse DNS zones configured, and, if yes, are they configured properly? Also, do you use both TCP/IP version 4 AND 6 and are they configured consistently across all the hosts?
    – Sergio
    Nov 5, 2015 at 13:57
  • Thanks Sergio. The name is the same and there are no DNS aliases set up. As for reverse DNS zones, I have to admit I'm not familiar. The TCP/IP settings these have been checked and although they were different have now been set to match with no effect.
    – L Woodall
    Nov 7, 2015 at 8:03
  • Issue this command on Client1: nslookup Server1 - let's suppose it returns 192.168.10.11, then issue nslookup 192.168.10.11 - it should return Server1. If it returns different name, this may be (one of) the cause(s). In regard to TCP/IP settings I meant you also to try to temporarily unselect IPv6 protocol on all the hosts.
    – Sergio
    Nov 7, 2015 at 9:34
  • Addition: repeat the tests on Server1: nslookup Client1 - let's suppose it gives 192.168.10.101, then run nslookup 192.168.10.101 - will it return Client1? (possibly continue on other hosts just for completeness).
    – Sergio
    Nov 7, 2015 at 10:15
  • Thanks again but we're not using a Name Server on the network, so the nslookup command fails each time. If I ping Server1 it responds from/with the correct IP address.
    – L Woodall
    Nov 7, 2015 at 11:38

3 Answers 3

Reset to default
0

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).
Improve this answer
1

Try running these commands from the machines that cannot access with hostnames:

nbtstat -RR

AND 

ipconfig /flushdns

NOTE: The hosts file also relies on a hard-coded IP address. You may want to consider configuring the server is a static IP address rather than DHCP.

Improve this answer
5
  • Thanks for your suggestion, Both commands ran successfully but this did not solve the issue.
    – L Woodall
    Nov 5, 2015 at 13:06
  • @LWoodall Delete the saved credential and then try it again without the saved credential from the machine with the issue. When you access it without the saved credential, are you typing in HOSTNAME\SHARENAME or IPADDRESS\SHARENAME?
    – Pimp Juice IT
    Nov 5, 2015 at 13:42
  • Again thanks for the suggestions, but I've still got the problem. When accessing via HOSTNAME\SHARENAME<code> it returns the error, when accessing via 'IPADDRESS\SHARENAME' it works as expected. Regarding the hosts file, I have tried adding the entries in with the correct IP addresses and have tried with a blank file, neither work.
    – L Woodall
    Nov 5, 2015 at 13:50
  • @LWoodall Can you do a side-by-side comparison of all TCP/IP settings from both client 1 and client 2 and see if you notice anything that is different in any of the settings? I assume you've already rebooted client 1 but if not, you may want to start with that too first. Disconnect any mapped drives on client 1 before you reboot too.
    – Pimp Juice IT
    Nov 5, 2015 at 13:54
  • I've completed a comparison of all the TCP/IP setting the only differences between the two were default gateway and the status of IPv6. Client 2 had IPv6 enabled, I set Client 1 to match Client 2 and restarted the computer (I had tried this earlier, you assumed correctly) with all mapped drives removed. This had no effect.
    – L Woodall
    Nov 7, 2015 at 7:55
0

Thanks to @Sergio and @PJMahoney We've now worked out what the problem was.

Client 1 contains 2 NICs, only NIC 1 is connected; however NIC 2 was configured with a static IP of the same address of Server 1. Evidence of this was that the Client was resolving the Server 1's IP to its own Hostname; (Thank you Sergio for telling me about ping -a).

It's always the stupid simple things.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .