Linux – Windows is unable to remember login credentials for DAV network share

linuxwebdavwindows

I have a WebDAV server running on a linux server through Apache, which I am then attempting to map on a windows machine.

The mapping works fine, I provide my credentials and it logs me in, but the windows machines are unable to remember my credentials and I am forced to hit the "Login" button every time I open a new document, as well as when the machine is turned on or woken up from sleep mode. On machines running anything lower then Windows 7, I am also forced to manually type my username and password into the login box for every resource used in a document (such as images in a word document and similar).

My apache setup uses Digest authentication with the following config;

    Alias /group /home/webdav/group
    <Location /group>
            DAV On
            AuthType Digest
            AuthName "group"
            AuthUserFile /home/webdav/users/group-password
            Require valid-user
    </Location>

I don't think the config is the reason for this odd behavior, but more that windows is unable to automatically respond to requests for login credentials (and in the situation with the machines running Vista and lower that they can't even save them for some odd reason).

Best Answer

May be mapping to a network drive can help?

net use x: "http://server.net:80/folder" /persistent:yes /User:<user> <password>

Note, that Windows XP doesn't support mapping to root directly, only to subfolders

Related Solutions

Centos – WebDAV on CentOS – getting 403 error when attempt to upload

I recently struggled with the same problem on my Fedora 10 system. In my case the culprit was some odd redirection that I was doing in Apache. Specifically, I use a content management system (Drupal, to be exact) that within it's .htaccess includes the following redirection logic to redirect missing files to a PHP script:

# Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

It makes sense that the above only affects the PUT method since in that case REQUEST_FILENAME does not exist.

Not having the WebDAV area inside of the Drupal area, which seems like a reasonable constraint, fixes the problem.

Also, I think it is likely that SELinux would result in a different error, but it's not mentioned in the discussion above. Did you try disabling SELinux?

Windows 7, HTTPS WebDav: Asks for password twice and fails. Any workarounds

I hate WebDAV.

I earned this hate during the process of getting WebDAV support onto my File Serving cluster. This is based on Server 2008 / IIS7, with the WebDAV plugin for IIS. It's clunky, and each individual WebDAV client out there expects to be able to talk to the WebDAV server over their own custom mix of the following:

Transport mechanism: HTTP or HTTPS
Session tracking: Cookies or HTTP-headers
Authentication: Basic, Digest, Kerberos, or NTLM authentication
Custom-port support may or may not be included.
The ability to connect to a root directory may or may not be present; WinXP certainly can't connect to http://davhost.example.com/, it has to connect to http://davhost.example.com/root/

WinXP and Win7 behave differently. Early WinXP versions can't talk HTTPS well at all. Some Windows versions, I forget which at the moment, only did session tracking via HTTP headers. Since I have a lot of OSX in my environment, 10.3, 10.4, 10.5, and 10.6 all subtly change what they support in terms of server capabilities. And of course, Gnome has its own requirements which plague our few Linux users.

I. Just. Can't. Win.

Right now I have Windows 7 and WinXP working just fine when serving WebDAV out of IIS7. It took a lot of crow-bar, but it's working. OSX works mostly for newer versions. Everyone else takes their chances.

Windows expects certain WebDAV verbs to be available. Check what your Win7 clients are getting when they attempt to connect and backtrack the error. If they're not getting one, it's a sign that the Windows host doesn't like the environment for some reason; perhaps you need to change session-tracking methods or you need to ensure your DAV hosts are in the correct IE Security Zone. Looking at the access logs is what allowed me to backtrack what Windows was expecting from a WebDAV server.

You'd think that doing WebDAV out of IIS to Windows clients would be simple, but you'd be mistaken like me.

Related Topic