Share via


0x80070043 The Network Name Cannot Be Found

Question

Tuesday, February 10, 2015 2:05 PM

We experienced a sudden drop in network share access in our environment today. Several of our users (100's) lost access to their day to day Data drive on their local office server. The issue was experienced across multiple office servers.

However the issue was sporadic and inconsistent, one user that couldn't access one share, the user next to them could but couldn't access the Data share on another office server.

We have multiple file servers each with multiple shares, our servers are running Server 2008 R2 and our workstations are Windows 7.

The issues was primarly experienced on the everyday 'Data' share, other shares on the same server were accessible. The folder was still accessible locally on the server and only appeared to be an issue for SMB connections.

We were able to identify a workaround by either restarting the client workstation which resolved the problem or by accessing the share using the FQDN instead of NETBIOS name.

We've troubleshooted name resolution and can confirm that Name resolution is working fine.

We've checked the Network provider order and this is also configured correctly on all file servers.

We've also ruled out the hotfix documented in KB2194664 as our servers and clients have a newer version of file mrxsmb10.sys and the hotfix is not applicable.

We performed a network capture on a file server that was receiving a connection attempt from a problem client and received the following results:

A successfull connection attempt to a share looks like this:

SMB2 170 Tree Connect Request Tree: \<SERVER>\IPC$
SMB2 138 Tree Connect Response
SMB2 222 Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \SERVER>\Users
SMB2 222 Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \SERVER>\Users
TCP 54 445→64647 [ACK] Seq=85 Ack=453 Win=256 Len=0
SMB2 131 Ioctl Response, Error: STATUS_NOT_FOUND
SMB2 172 Tree Connect Request Tree: \<SERVER>\Users
SMB2 138 Tree Connect Response

The connection attempt to the problem share looks like this:

SMB2 170 Tree Connect Request Tree: \<SERVER>\IPC$
SMB2 138 Tree Connect Response
SMB2 220 Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \SERVER>\Users
SMB2 220 Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \SERVER>\Users
TCP 54 445→64647 [ACK] Seq=85 Ack=453 Win=256 Len=0
SMB2 131 Ioctl Response, Error: STATUS_NOT_FOUND
SMB2 131 Ioctl Response, Error: STATUS_NOT_FOUND
TCP 60 64647→445 [ACK] Seq=449 Ack=239 Win=253 Len=0
SMB2 220 Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \SERVER>\Data
SMB2 131 Ioctl Response, Error: STATUS_NOT_FOUND
SMB2 220 Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \SERVER>\Data
SMB2 131 Ioctl Response, Error: STATUS_NOT_FOUND
SMB2 220 Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \SERVER>\Data
SMB2 131 Ioctl Response, Error: STATUS_NOT_FOUND
SMB2 220 Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \SERVER>\Data
SMB2 131 Ioctl Response, Error: STATUS_NOT_FOUND
SMB2 220 Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \SERVER>\Data
SMB2 131 Ioctl Response, Error: STATUS_NOT_FOUND
SMB2 220 Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \SERVER>\Data
SMB2 131 Ioctl Response, Error: STATUS_NOT_FOUND

We've raised a support ticket with Microsoft as this issue now has us completely at a loss and all current community suggestions for the 'The Network Name Cannot Be Found' error message have been thoroughly explored (name resolution, network provider order, KB2194664)

We'd appreciate any assistance anyone is able to offer

Kriss Milne | MCSE

*Please click 'Vote As Helpful' or 'Mark as Answer' if a post has helped you or answered your question*

All replies (8)

Wednesday, February 11, 2015 3:27 PM ✅Answered | 1 vote

We have managed to identify the root cause of our specific problem which I'll document for the community.

Only the Data share was experiencing the problem across multiple files servers, we identified on one system producing the problem that the share had a reference to an incorrect DFS referral. The DFS referral did not however exist in our DFS namespace.

After further investigation we found a tombstone record in Active Directory for this incorrect DFS referral. It seems that the record had been incorrectly created and shortly after deleted, however, not before replicating across our environment and being cached by the client DFS referral cache.

The resolution to the inability to access the share due to an incorrect cached DFS referral was any of the following:

  • Restart the client workstation
  • Use a different name to connect to the share (FQDN, IP Address, Netbios)
  • Flush the DFS Referral cache using 'DFSUTIL CACHE REFERRAL FLUSH'

This does highlight an issue with the DFS Referral cache though were if the record has been cached and removed from AD the record does not flush from the cache after the default period of time (1800 seconds or 30 minutes)

Kriss Milne | MCSE

*Please click 'Vote As Helpful' or 'Mark as Answer' if a post has helped you or answered your question*


Wednesday, February 11, 2015 2:32 PM

Hi,

Above all, since a Microsoft ticket is submitted, it is recommended to stay with MS online support to find out a solution. More suggestions at a time may cause confusion.

As you mentioned that a hotfix cannot be installed due to file version, please test the following hotfix rollup which will also update SMB related files. It is recommended to be installed on Windows 7 SP1 and Windows 2008 R2 SP1 systems.

http://support.microsoft.com/kb/2775511

Meanwhile if NetBIOS will not work but FQDN will, and name resolution is not the cause, please check if DNS suffix on problematic computer is setup correctly.

Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Support, contact [email protected].


Wednesday, February 11, 2015 3:19 PM

Thank you for the response Shaon

Apologies, our machines are also running Service Pack 1, I am aware of hotfix rollup 2775511 however cannot confirm that this is deployed across our environment.

With regards to the name resolution, I specified that we have confirmed name resolution is not a problem in order to reduce suggestions of checking name resolution. Checking that the respective file server could be resolved by the netbios name and fully qualified domain name were part of the initial troubleshooting, also, if this were the cause, that wouldn't explain the ability to access other shares on the same server.

Kriss Milne | MCSE

*Please click 'Vote As Helpful' or 'Mark as Answer' if a post has helped you or answered your question*


Sunday, January 3, 2016 4:37 PM

This worked for me:  Flush the DFS Referral cache using 'DFSUTIL CACHE REFERRAL FLUSH'

Thank you for posting this.


Tuesday, April 3, 2018 7:26 PM | 1 vote

ghdfjwdfgsd


Tuesday, April 16, 2019 4:18 PM

Ok so that did not work!  

Here is my issue.   I have a namespace called fileserver.   It has several target folder shortcuts.   I have a folder target called Infrastructure.   I assigned 2 targets to 2 different servers.   They are all in the same domain.  The second target is located at a different site but is on the same domain.  I can reach the share directly from my location.   So when the folder has both targets enabled I can access the share. I can even go into the setting and set the active target to my other server and it works. But when I disable the target at the other location and go back to access the folder through the name space it give me an error. Element not found. You might not have permission to use this network resource.


Tuesday, April 16, 2019 4:27 PM

Also when I do a dfsutil /pktinfo I see it as a taregetset but its not setting it to active?


Tuesday, April 16, 2019 4:43 PM

Here is pktinfo. These are setup exactly the same. DFSTEST6 works. Infrastructure does not and say ouside my dom. I am assuming that is messing it up. See below.

C:\Windows\system32>dfsutil /pktinfo
6 entries...
Entry: \FILESERVER2\fileserver\DFSTest6
ShortEntry: \FILESERVER2\fileserver\DFSTest6
Expires in 1753 seconds
UseCount: 0 Type:0x1 ( DFS )
   0:[\VFS2-H-DC1\DFSTest6] AccessStatus: 0 ( ACTIVE TARGETSET )

Entry: \FILESERVER2\fileserver\Infrastructure
ShortEntry: \FILESERVER2\fileserver\Infrastructure
Expires in 294 seconds
UseCount: 0 Type:0x10 ( OUTSIDE_MY_DOM )
   0:[\VFS2-H-DC1\Infrastructure] ( TARGETSET )

Entry: \MyDomainName\fileserver
ShortEntry: \MyDomainName\fileserver
Expires in 242 seconds
UseCount: 2 Type:0x81 ( REFERRAL_SVC DFS )
   0:[\FILESERVER2\Fileserver] AccessStatus: 0 ( ACTIVE TARGETSET )
   1:[\VFS2-H-DC1\Fileserver] ( TARGETSET )

Entry: \MyDomainName\MCG
ShortEntry: \MyDomainName\MCG
Expires in 243 seconds
UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS )
   0:[\FILESERVER2\MCG] AccessStatus: 0 ( ACTIVE TARGETSET )

Entry: \MyDomainName\Software
ShortEntry: \MyDomainName\Software
Expires in 243 seconds
UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS )
   0:[\FILESERVER2\Software] AccessStatus: 0 ( ACTIVE TARGETSET )

Entry: \MyDomainName\Users
ShortEntry: \MyDomainName\Users
Expires in 243 seconds
UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS )
   0:[\FILESERVER2\Users] AccessStatus: 0 ( ACTIVE TARGETSET )