We help IT Professionals succeed at work.

Unable to map a share by name after server has been idle for some time

network newbie
network newbie asked
on
I have CIFS as the member server with a windows PDC. If i map a share(by name), then wait 15 min and try to map another share by its name, its gives the error STATUS_BAD_NETWORK_NAME. However, I am able to map the same share using IP address.
Any thoughts as to what could be the issue here? Could it have something to do with NTLM?
Comment
Watch Question

Dan McFaddenSystems Engineer

Commented:
The error has to do with the way the request and reply are communicated.  The answer coming back basically says that the info received is in the wrong format.

I would double check the TCP/IP config on the file server.  I would also make sure that the Provider order bindings are in the correct order.

Depending on the server OS, go to:  Control Panel > Network and Internet > Network Connections.  Otherwise known and change Adapter Settings where you will see a list of the network cards.  The do the following:

1. press and release the ALT key.  This will drop down the "File" menu
2. Select Advanced then Advanced Settings
3. On the "Adapters and Bindings" tab, under the "Connections" area, make sure that your active network connection is on the top.
4. On the "Adapters and Bindings" tab, under the "Bindings for ..." area, I would make sure that "TCP/IPv4" is on top for all services.
5. On the "Provider Order" tab, make sure the "Microsoft Windows Network" is on top.
6. OK your way out.

There is no need to reboot, but feel free to do so if it makes you feel good.  Test mapping your shares.

Dan

Author

Commented:
The Provider order tab has "Windows remote desktop Session host server network provider" on top. But that's because I remote desktop to the PDC. That couldn't be a problem, right?
All other fields are set as expected.
Dan McFaddenSystems Engineer

Commented:
Whether you RDP to a server or not, it shouldn't be the first protocol binding.    Microsoft Windows Network should be the top binding.  Especially on a Domain Controller.

I recommend changing the binding order.

Dan

Author

Commented:
I would try that. Can you please tell me why that would affect mapping of shares?
I need to be absolutely sure before I do it. Dont want it having unwanted effects on the other systems in the domain.
Dan McFaddenSystems Engineer

Commented:
The binding order tells the OS with which protocol to process requests and in which order to attempt to interpret the requests.  If your bindings are in the wrong order, the OS may respond with the wrong the reply message or it may not be able to understand the incoming requests for communication.

Reordering the bindings will not negatively impact a properly configured server.  Why Microsoft does not place "Microsoft Windows Networking" first as a default is unknown.  But as part of a standard server build, this is always done on servers in my workplace.

Another thing is to ensure that TCP/IPv4 is first in the bindings.  If IPv6 is first, your server will first try to speak IPv6 on your network until the IPv6 protocol timeout (if, of course, your network does not support IPv6).  It will then try to use IPv4.  So reordering bindings is also something of a performance tweak.

Whatever your primary communications protocols are, they should be listed first.  In your case, IPv4 and Microsoft Windows Networking.

Dan
I agree with Dan McFadden 100% with the Provider Order. You may also find the following link interesting as well.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/4d40dd77-3c1f-4c94-9688-a8a710870a86/windows-2008-r2-server-unable-to-browse-unc-shares

What OS is your File Server?

Author

Commented:
What OS is your File Server?
openVMS.
Dan McFaddenSystems Engineer

Commented:
So, first adjust the binding order on the Microsoft OS clients.  If the issue persists, I suggest you go over the CIFS config on the OpenVMS server.

Dan

Author

Commented:
Thanks. I changed the order but the problem still persists. Looks to be a CIFS issue.
Are your network drivers up-to-date

Author

Commented:
Yes. The more I look at it, the more it seems like a Kerberos issue. its using ptrpub_cache as the credential cache instead of winbindd_cache when the request fails.
What about changing the cache timeout cache settings ahead of time..

http://serverfault.com/questions/482174/slow-shared-folder-refresh-on-windows-7
I finally figured it out. This was happening because of one of the environment variables not being set properly. So when the credential cache timed out, the server would try to refresh it and would access the wrong cache. As a result, it  was unable to authenticate users thereafter.

Author

Commented:
I was finally able to resolve the issue after all these days. Thought I will share it with others. Hence posted the solution.