Windows 2008 R2 File Share

Dear Experts,

I have two Windows server on different subnets and domains - let's call them A.local and B.local.  I can ping both of them by IP, hostname and FQDN.  

When I "\\hostnameB\share" on A, I got "Windows cannot access \\hostname\share.  Check the spelling of the name.  Otherwise, there might be a problem with your network.  To try to identify and resolve network properties, click Diagnose.  Error code: 0x800004005 Unspecified error."

Everything works find if I do "\\hostnameA\share" from B.

I checked the firewall, virusscan and such... nothing work on A when trying to get to resources on B.  Could you please give me some clues?  Thanks.
swgitIT ProfessionalAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Edward PamiasTeam Lead RRS DeskCommented:
did you check the share on B, to make sure its setup correctly? Permissions, the name etc...
swgitIT ProfessionalAuthor Commented:
yes.. i did.. all other subnets get to it just fine

It almost sounds like Windows firewall is stricter on hostnameA than hostnameB.  Are both servers running Windows 2008?  If so, compare the firewall rules on both are similar and you explicitly allow SMB, filesharing services and port through the firewall on hostnameA.

- In Windows Firewall, click Advanced settings, and in the console tree, click Inbound Rules.
- Under Inbound Rules, locate the rules File and Printer Sharing (NB-Session-In) and File and Printer Sharing (SMB-In).
- For each rule, right-click the rule, and then click Enable Rule.


Also, if you are accessing a share on hostnameA then try logging in using a username/account from domain of hostnameA.  Remember that to state the username as "domain\username"  If that doesn't work, then try a test share folder with EVERYONE permission, and try to login using a local account "hostname\username".  If any of those works then you know it's a Windows Authentication issue.  If you don't get that far then it may be a firewall issue.  Also check the event logs for hints on the server hosting the share for clues.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
CEOs need to know what they should worry about

Nearly every week during the past few years has featured a headline about the latest data breach, malware attack, ransomware demand, or unrecoverable corporate data loss. Those stories are frequently followed by news that the CEOs at those companies were forced to resign.

swgitIT ProfessionalAuthor Commented:
The only difference I found was that Windows Firewall on B was completely OFF... so I went ahead and turned OFF Windows Firewall on A... also disabled GP related to the Firewall, and force gpupdate.  However, the same error occurs.  I tried to connect to the share, I got Error code: 0x80070035 - the network path was not found (this error is for both hostname and IP)
But you are able to ping this same server using hostname as well as IP right and that you have no problem mapping to the same server from a machine within the same domain.  Is this correct?

Can you check something quickly, ensure the TCP/IP NetBIOS Helper service is running on both the workstation as well as the server you're trying to connect to?  Then try again.
Edward PamiasTeam Lead RRS DeskCommented:
This is what Microsoft asked another person to do to fix their issues. I would assume you would do this on the server with the issue. If what Wayne88 does not fix it, try below.

1. Remove the DNS entries from TCP/IP properties

2. Restart the machine

3. Notice, sharing is now working!

4. Reconfigure the DNS entries in TCP/IP properties
swgitIT ProfessionalAuthor Commented:
Thanks, both.  I ended up talking to MS, and with the use of Microsoft Network Monitor 3.4, we were able to pin down the problem caused by an acknowledgement reset on port 445 at the perimeter fw.
Thanks for the points and getting back to us.  Cheers!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.