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 fileserver.domain.com 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 fileserver.domain.com 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.
Best Answer
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.
Edit:
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<