Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


Can only access windows shares using hostnames or FQDN, cannot access using IP address of host.

Posted on 2011-03-10
Medium Priority
Last Modified: 2013-12-02

I recently became the sysadmin at a company that had not previously had one. I inherited a situation where there were 2x 2008 (32bit/Standard) domain controllers, and one had a broken NIC. That had to be forcefully demoted. Over the last few weeks I've been migrating everything to 2008R2, but in some places I couldn't do a real migration and simply had to recreate the configuration. Just about everything works but I have a really bizarre network sharing issue.

Domain Controllers:, - Shares can be browsed by IP or hostname.
NAS, Old windows server - Shares can be browsed by hostname or FQDN, but NOT IP.
Windows servers which has local user auth- Shares can be browsed by hostname or IP.

I will go through an example of this below:

"ping NAS" returns "reply from"
"nslookup" returns "nas.local.domain"
"net use t: \\nas.local.domain\share" returns "The command completed successfully" (deleted after)
"net use t: \\\share" returns "System error 233 has occurred. No process is on the other end of the pipe."

At first I thought this was specific to the NAS, but I've since learned that all older windows shares have this problem. New shares created under Vista and old shares that allowed local user authentication seem to work. New folders created on the NAS do not work either.

There is no firewall between devices suffering this issue. No windows firewalls enabled. I cannot at present use packet sniffers or port scanners. Ideas? Questions?
Question by:BSAFH
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4

Accepted Solution

arunexp earned 1500 total points
ID: 35104311
You could try changing the client authentication level to normal NTLM and NTLM..this can be done form registry..
we had similar issues when we rolled out w7.. we put packet sniffer and identified it as NAS issue and NAS vendor suggested code upgrade..

Author Comment

ID: 35105035
Unfortunately my working environment requires lots of security. I will see if I can free up a host for testing. Keep in mind, this doesn't just apply to the NAS. It also applies to Windows server hosts (2003, 2008). They're able to browse to their own IP, but other computers cant connect unless using the hostname.

Author Comment

ID: 35185940
I have new information, although it is a little late.
It turns out that each of the windows shares had a slightly different issue, most of them are taken care of. As it stands, only the NAS and 1 Windows Server host cannot be reached. Different reasons.

The NAS will work if I reset it to factory defaults (No AD) but stops immediately after joining the domain. I have therefore opened a case with the NAS vendor as this is likely an issue with their firmware. After doing a tcpdump of the communications with the NAS it looks like its running a linux kernel and samba for sharing.

The last windows host to have a problem, when I trace it it sets up an SMB session with dialect 2.002. The only descriptive packets I see are (poor formatting, copying from handwritten notes): Error Code 412 Status fs driver required ioctl, nt status system error code 34, status access denied tree connect. http response http 1.1 status not found url:/c$. nt status system error 13, status invalid parameter query information, nt status system system error code 94 status_no_logon_servers session setup. 22 status more processing required.

I'm ok with just blaming the nas vendor for that device, but the windows issue I should still be able to fix. It is running Windows Server 2008 Standard.

Author Closing Comment

ID: 35229274
Kerberos can't authenticate against IP, something to do with SPNs require a hostname. NTLMv2 apparently not supported in later versions of Samba or something, lots of NAS vendors use Samba. I haven't figured out yet why my 2008 box can't auth with my 2008r2 but it is probably something similar.

Author Comment

ID: 35229296
LM Compat has 5 levels. 2008R2 defaults to level 4 (NTLMv2 response only). Apparently a lot of NAS boxes use Samba, which has some sort of issue with newer versions of auth (ntlm2, kerberos). My NAS vendor recommended I swap to LM/NTLM send. Not going to happen, but that certainly makes it seem like that it what it is.

I read something about kerberos not being able to auth things on IP, it has to assign an SPN and it can't do that to an IP. My level is too low to get it all. I'm just writing this comment to condense some of my google searches into 1 result for future searchers.

You can modify your policy in secpol or group policy- local policies, security, network settings - network security: LAN Manager Authentication Level.

Featured Post

On Demand Webinar: Networking for the Cloud Era

Did you know SD-WANs can improve network connectivity? Check out this webinar to learn how an SD-WAN simplified, one-click tool can help you migrate and manage data in the cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

For anyone that has accidentally used newSID with Server 2008 R2 (like I did) and hasn't been able to get the server running again because you were unlucky (as I was) and had no backups - I was able to get things working by doing a Registry Hive rec…
Group policies can be applied selectively to specific devices with the help of groups. Utilising this, it is possible to phase-in group policies, over a period of time, by randomly adding non-members user or computers at a set interval, to a group f…
This tutorial will show how to configure a new Backup Exec 2012 server and move an existing database to that server with the use of the BEUtility. Install Backup Exec 2012 on the new server and apply all of the latest hotfixes and service packs. The…
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…
Suggested Courses

661 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question