Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a Nexenta file server which is using domain authentication for users. All of the Windows 7 machines on our network can connect and use the shares on it without any issues using either \XX.YY.ZZ.AA\share or \fileserver\share.

We added a new Windows 7 machine to our domain, and for some reason I can't access the file server using either \XX.YY.ZZ.AA\share or \fileserver\share. I can ping and connect to the fileserver's web interface from the new machine, but cannot connect to shares even when logged onto this new machine with a user account which can access the share from other working Windows 7 machines.

When I attempt to connect by IP address I get the error:

Check the spelling of the name. Otherwise, there might be a problem with your network. To try to identify and resolve network problems, click Diagnose.

When I attempt to connect by machine name I get the error:

\fileserver\share is not accessable. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.

The inability to connect to the share by IP number seems extremely odd to me.

New Info (1) Another tidbit of information. While connecting was working from my Windows 7 machine I ran a ipconfig /flushdns, and suddenly it stopped working. Can't connect to it by IP or by name now.

New Info (2) To clarify New Info (1), the file server has two IP numbers, one which it uses just to connect to its SAN, the other to connect to the general network. When I CAN NOT connect to it, I can ping it without any issue: i.e. I see:

ping fileserver Pinging XXX.XXX.XXX.XX with 32 bytes of data: Reply from XXX.XXX.XXX.XXX: bytes=32 time<1ms TTL=254

If I run ipconfig /flushdns, it will occasionally pick up the SAN interface IP for that name. Now when I ping the fileserver, I can't reach it (as expected)

ping fileserver Pinging YYY.YYY.YYY.YYY with 32 bytes of data: Timeout

BUT, and here is the weird thing. I now CAN connect to the share \fileserver.

I really wish MS gave you a better way to turn on logging in the OS. I have a feeling that what is going on is related to the client trying to lookup the server name using DNS, and attempting to connect, and that when it can't (because DNS is returning the IP of the SAN interface I can't reach), that it falls back to NETBIOS, which for some reason makes it work.

share|improve this question
Was this new Windows 7 computer cloned? Have you checked Credntial Manager for stored credentials for the Share that might be causing the issue? – joeqwerty Jan 31 '13 at 16:32
If you can't connect via ip address then DNS isn't relevant to the problem. – joeqwerty Jan 31 '13 at 22:17
I think that DNS is only slightly relevant in that I believe that the share is working when DNS is not working. – Benjamin Peikes Feb 1 '13 at 21:57

I'd start by comparing the LMCompatiblityLevel setting between the non-working and working machines. I'm getting a feeling that something is fishy with NTLM protocol negotiation between the client and server.

If you can, get a packet capture of the traffic between the client and server for each attempt you described. There's nothing like actually seeing what's going on with the bits on the wire.


I'm having a hard time coming up with DNS as the problem. That doesn't explain the message you're seeing when attempting to access the machines by IP address, which sure looks like the TCP connection isn't coming up. I could see DNS (Kerberos and the domain name in the SPN, specifically) being involved if it looked like the TCP connection was coming up but authentication was failing.

Capture some traffic. The packets want to tell you what's going on... >smile<

share|improve this answer
Where is that setting found on Windows 7? – Benjamin Peikes Jan 31 '13 at 22:21
You can look at it directly in the registry at: HKLM\SYSTEM\CurrentControlSet\Control\Lsa It can be manipulated through Group Policy, as well. – Evan Anderson Jan 31 '13 at 22:24
LMCompatiblityLevel doesn't appear to be the issue either. The issue is much stranger. I believe it has to do with DNS. – Benjamin Peikes Feb 1 '13 at 21:39
I'll drop on an edit. – Evan Anderson Feb 1 '13 at 21:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.