I set up a Liferay portal 6.1.1 CE GA2 and create some folders and upload some files to the Documents and Media. After that I tried to use the webdav URL (provided in "Access from Desktop" function) to access the folders in Windows 7, it prompts me username and password and I tried many times (using admin and other normal user account) but none of them work. I captured the debug log listed below:

## Set the list of article types. The display text of each of the article# types is set in content/Language.properties.# ROOT/WEB-INF/classes/content/Language-ext.properties# ROOT/WEB-INF/classes/content/Language-ext_en.properties# ROOT/WEB-INF/classes/content/Language-ext_en-US.properties#journal.article.types=announcements,blogs,general,news,press-release,test

I was struggling over a week with the same problem... But in my case I was trying to implement (for learning purposes) small WebDAV server in Java on Tomcat. Whatever I did, Windows all the time complained about something (and it turned out those messages had absolutely NOTHING in common with the real problem), but all other WebDAV clients worked just fine with my server. What the heck? Well, pursuing the thing, I found out that Box service (disk space hosted on a cloud) have also DAV support for the storage. I was very surprised, when I found out, that mapping this service (running on Sabredav) as a drive worked out of box with no problems whatsoever. I just typed URL in the dialog window (well, I also checked "use different credentials") and it just... worked! So if there is ONE service that actually works, it must be possible then to make it work with my server, right? ;-) As to this moment, false error messages form MiniRedir made me think it's configuration problem. So I spend literally days on trying different approaches, settings, a.s.o. All futile. Then I tried this: I used curl (from command line) to connect to Box WebDAV, get response for OPTIONS and PROPFIND and use exactly the same headers AND content (XML) in my server for these HTTP request. At this point my intention was to completely fake the response, but it would allowed me to at least use tested and working multistatus response. To my surprise mapping worked at once! And as I didn't change a thing in the configuration, it must been involved in the content actually. When I changed multistatus to XML generated from my server, again I wasn't able to map the drive. Switching back to faked reply --- and all started to work again. So I shortened the Box response to single minimal response element that still worked and interchangeably I was trying to send similar generated content. But even if the XML was pretty the same, fake one worked and generated didn't. Cursing and berating didn't help. One thing that actually differed was file name, file size and creation/update timestamps. Finally I found the culprit: getlastmodified. For some unknown reason, when I generated the date, it didn't work, but when I copy-pasted it from Box response, I was able to map the drive. What da?... So I went into WebDAV specification and RFC-1123 specifically which then pointed me to RFC-2616. What it turned out? That HTTP-date (used in getlastmodified element) must be represented in GMT (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3 --- see from "All HTTP date/time stamps (...)"). In my case date formatter was using CEST timezone... As I changed my code to use GMT oriented timestamps, I was finally able to map drives flawlessly.

As you can see, timezone is CST. If you change the time to 18:17:25 GMT, it should work. If you can't change it in the code, you would probably have to change system timzeone (or maybe some other settings). At least, from my experience, you won't be able to map anything, until you fix dates. And believe me --- all those "helpful" error messages I got, had nothing to do with real case.