So for the longest time I couldn’t figure out why on some computers I could use a UNC path to get to SharePoint sites’ resources, and on others I could. Now I think I finally have the answer.

The mechanism is that if you have a WSS site (and Admin privs on that site) at a URL/URI like: http://server/sites/testsite1/, you should be able to open Windows Explorer (not Internet Explorer) and open its UNC path: \\server\sites\testsite1\. If you so so, in Explorer, you should be able to see the full “directory structure” (I put this in quotes because it doesn’t actually exist, but is a figment of your, SharePoint’s and SQL Server’s imaginations), including directory names like “_catalogs”, “_fpdatasources”, “_private”, the ever popular “images”, a directory for non-Document Library, non-Picture Library lists called “Lists”, a folder for each sub-site and a folder for each Document Library or Picture Library, various aspx pages, etc.

Using this UNC Path view, you can do normal file operations, but do be careful, since if you delete a file you probably can’t get it back.

Anyhow, I’d been finding that sometimes this UNC path worked in Explorer and sometimes it didn’t. It didn’t appear to be related to a particular user permissions set or domain login account, but changed computer to computer.

Here’s the error message I’d get when it didn’t work (click to see full size):

Here’s the kind of folder structure I’d see when it did work (click to see full size):

It turned out, after trial and error, that the real difference here was that one computer I was using was running the WebClient service (where the connection worked), and the other wasn’t (where the connection did not).

No, I couldn’t easily find it documented on Microsoft’s support sites.