Recently following an unrelated upgrade to my VirtualBox client, one of my host VM’s started exhibiting unusual behavior. While it was possible to retrieve directory listings from a UNC path, any attempt to map a drive would result in a standard although somewhat generic error message.


System error 67 has occurred.
The network name cannot be found.

My first impression is that something was wrong with my network configuration. After exhaustively troubleshooting various network configuration scenarios, the results were inconclusive. Oddly enough, the UNC path could be listed using the following convention:


Other VM’s on the same workstation were functioning correctly so this was clearly an isolated problem. There was very little information on this from either Microsoft or any of the standard outlets, but a network trace using Wireshark suddenly provided the enlightenment that was needed.

Unlike a direct UNC request, when a drive was mapped the result was an HTTP request:

  Request Method: PROPFIND
  Request URI: /SHARE
  Request Version: HTTP/1.1
Depth: 0
translate: f
User-Agent: Microsoft-WebDAV-MiniRedir/5.1.2600
Content-Length: 0
Connection: Keep-Alive

Evidently, my XP workstation was attempting a WebDAV connection to the file server when it should have been an SMB (CIFS) request. My first inclination was to disable the WebDAV support in XP, but after a cryptic registry modification to make this change, the effect was the same. Then a review of the advanced settings for my network provided the final clue:

Network Provider Order

According to this,  the Microsoft Windows Network was missing. This is particularly disconcerting in light of the fact that my workstation was connected to a Windows domain and that I had logged-in using my domain credentials.

As it turned out, removing and adding back in the Client for Microsoft Network client for my network adapter was enough to get Windows back on the network. The error most likely coincided with my VirtualBox upgrade and I suspect the VirtualBox Shared Folder provider was the culprit.

The obvious lesson here is that just because some of your Windows SMB (CIFS) requests succeed it doesn’t imply that your workstation is fully functional.