Webdav broken recently (401) for keepass clients


Nextcloud version (eg, 20.0.5): 26.0.0
Operating system and version: fedora-iot 37, running containers
Container image: Docker → 26.0.0

The issue you are facing:

All the sudden my keepass clients stopped syncing, webdav gives timeout. Different accounts, different clients and operating systems. Keepass2android, keepassium, several android devices and iphone. Might be coincidense that the podman just upgraded nextcloud to 26.

Is this the first time you’ve seen this error? Yes

Steps to replicate it:

  1. Configure application password
  2. add webdav file path to password client: https://example.com/remote.php/dav/files/USERNAME/pwd.file
  3. use created credentials

The output of your Nextcloud log in Admin > Logging:

nothing at the time of error

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

$CONFIG = array (                                                                                                                                     
  'instanceid' => 'xxx',
  'passwordsalt' => 'xxx',
  'dbtype' => 'mysql',
  'version' => '',
  'dbname' => 'x',
  'dbhost' => 'x',
  'dbtableprefix' => 'x',
  'dbuser' => 'x',
  'dbpassword' => 'x',
  'installed' => true,
  'theme' => '',
  'maintenance' => false,
  'trusted_domains' => 
  array (
    0 => 'x.x.x',
    1 => 'y.y:8090',
  'mail_smtpmode' => 'smtp',
  'mail_from_address' => 'do-not-reply',
  'mail_domain' => 'x',
  'mail_smtphost' => 'x',
  'mail_smtpport' => 'x',
  'secret' => 'x',
  'forcessl' => false,
  'loglevel' => 3,
  'trashbin_retention_obligation' => 'auto',
  'htaccess.RewriteBase' => '/',
  'appstore.experimental.enabled' => true,
  'overwrite.cli.url' => 'https://x.x.x',
  'overwriteprotocol' => 'https',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'apps_paths' => 
  array (
    0 => 
    array (
      'path' => '/var/www/html/apps',
      'url' => '/apps',
      'writable' => false,
    1 => 
    array (
      'path' => '/var/www/html/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
  'mail_smtpauthtype' => 'PLAIN',
  'app_install_overwrite' => 
  array (
    0 => 'mindmaps',
    1 => 'keeweb',
    2 => 'drawio',
  'mysql.utf8mb4' => true,
  'default_phone_region' => 'x',

The output of your Apache/nginx/system log:

Here I started following the log for the time of keepass2android tries to do database sync. This has worked years until today.

The interestin connection is the use iii with the problem_file. Names changed. See how it gets 401 at first try. This is behind HAproxy in container, so all source addresses seem to be, I think it’s some podman nat there. - - [26/Mar/2023:14:55:49 +0000] "GET /remote.php/webdav/sync/problem_file.kdbx HTTP/1.1" 401 1884 "-" "okhttp/4.10.0-RC1" - - [26/Mar/2023:14:55:50 +0000] "GET /ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1" 304 763 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/110.0" - aaa [26/Mar/2023:14:55:55 +0000] "PROPFIND /remote.php/dav/files/aaa/ HTTP/1.1" 207 1073 "-" "Mozilla/5.0 (Macintosh) mirall/3.7.4git (build 14240) (Nextcloud, osx-22.3.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)" - iii [26/Mar/2023:14:56:02 +0000] "PROPFIND /remote.php/dav/files/iii/ HTTP/1.1" 207 1075 "-" "Mozilla/5.0 (Linux) mirall/3.7.3git (Nextcloud, fedora-6.1.15-200.fc37.x86_64 ClientArchitecture: x86_64 OsArchitecture: x86_64)" - - [26/Mar/2023:14:55:42 +0000] "GET /apps/logreader/poll?lastReqId=VR7M97krIvqWDJmXM5MI HTTP/1.1" 200 793 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/110.0" - - [26/Mar/2023:14:56:03 +0000] "OPTIONS / HTTP/1.0" 302 1765 "-" "-" - iii [26/Mar/2023:14:55:49 +0000] "GET /remote.php/webdav/sync/problem_file.kdbx HTTP/1.1" 200 34713 "-" "okhttp/4.10.0-RC1" - - [26/Mar/2023:14:56:15 +0000] "GET /csrftoken HTTP/1.1" 200 894 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/110.0" - iii [26/Mar/2023:14:56:16 +0000] "GET /ocs/v2.php/apps/user_status/api/v1/user_status?format=json HTTP/1.1" 200 922 "-" "Mozilla/5.0 (Linux) mirall/3.7.3git (Nextcloud, fedora-6.1.15-200.fc37.x86_64 ClientArchitecture: x86_64 OsArchitecture: x86_64)" - iii [26/Mar/2023:14:56:16 +0000] "GET /ocs/v2.php/apps/notifications/api/v2/notifications?format=json HTTP/1.1" 200 925 "-" "Mozilla/5.0 (Linux) mirall/3.7.3git (Nextcloud, fedora-6.1.15-200.fc37.x86_64 ClientArchitecture: x86_64 OsArchitecture: x86_64)" - - [26/Mar/2023:14:56:18 +0000] "GET /ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1" 304 766 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/ Safari/537.36" - - [26/Mar/2023:14:56:20 +0000] "GET /ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1" 304 763 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/110.0"

Output errors in nextcloud.log in /var/www/ or as admin user in top right menu, filtering for errors. Use a pastebin service if necessary.

No errors during the time of degubbing this in nextcloud.log

It says timeout for the clients. When I tried with nautilus, it gets in but the initial access takes a while. Why is there 401 for the keepass2android in nginx log?

This is really odd, when I press from mobile to refresh the keepass file, i get immediately 401 responce in logs, but client keeps waiting, untli like 30 secs late mobile says timeout, and immediately after I get the 200 responce in nginx log. But the nginx timestamp is from the very same second as the first 401 responce: - - [26/Mar/2023:16:09:58 +0000] "GET /remote.php/dav/files/iii/sync/file.kdbx HTTP/1.1" 401 2031 "-" "okhttp/4.10.0-RC1" - iii [26/Mar/2023:16:09:58 +0000] "GET /remote.php/dav/files/iii/sync/file.kdbx HTTP/1.1" 200 26550 "-" "okhttp/4.10.0-RC1"

This was while grepping the user. You can see from the original log how it has even later timestamp logs in between, then all the sudden older 200 response pops up. Why?

1 Like

I can’t help with any of this, but I ran into the same problem. Does not matter which OS or client, all KeePass queries take forever or won’t execute after timeout.

Oh, and I’m still on NC 25.0.5

1 Like

Thanks for sharing that I’m not the only one. I have auto update on via podman. After week or so it all the sudden worked again. The problem was also with both android and iphone clients. Luckily it happens to work now. Let’s see how long…

OS: Ubuntu 22.04 (Strato V-Server with Plesk)
NC: 26.0.1

Hi there,
I have a similar problem.
I’ve updated my webserver from Ubuntu 20.04 to 22.04 and my nextcloud from 25.0.6 to 26.0.1.
The error was not on Ubuntu 20.04 (25.0.5), but with 22.04 and nc 25.0.6 and nc 26.0.1.

The Error msg is:
Failed to load the specified file!
The request was aborted. Could not create SSL/TLS secure channel.
(the error msg is in german, this is the english version)

Because I’ve updated basically everthing besides keepass I really don’t know where to start looking.
Webdav seems to work because I can download pdf files with Firefox over webdav.
SSH and SSL seems to work because the Keepass2Android does not have a problem accessing the same file via webdav.
So that leaves me with keepass.
I’ve tried to connect from another pc with the same keepass, which did’nt work.
I have had a first look at some logfiles but haven’t seen something I could point to the problem.

I’ve checked the nextcloud log files. There is nothing in there.
The request does not seem to reach nextcloud but is blocked from somewhere/something else.
The Apache Logfiles were also empty.

I keep looking.

I would appreciate a reply if someone can pin point the problem to somewhere specific.


Check against the support forums or chats or git issues for keepass2android and similar. Link them back here.

What Keepass app are you using, on what system, and how are you trying to access the Keepass-file?

On Android I use KeePassDX | F-Droid - Free and Open Source Android App Repository, (keepass2android never worked well for me) only to access an existing file. If I need a password I just tap on the KeePass file in the Nextcloud app, and then it opens in KeePassDX, that’s it.

Is this specific to Keeweb?

for Android I use Keepass2Android. No Problems here, the app works just fine. (Pixel 4a, latest Android 13).
For Windows (10 latest update) I use Standard keepass 2.53.1. The remote file path for webdav looks like this:
https://nc.mydomain.de/remote.php/webdav/folder1/KeePass/keepassDB.kpdbx (I can download pdfs via webdav an this path structure just fine.)
I do not use a separate device or session login for keepass on windows.


So I did a bit of testing and it seems that my problem only exists on my local network. When accessing keepass with keepass2android on a mobile network or through my laptop via the keepass2 app and a mobile network, everything works fine. First I thought my pihole instance might be the problem, but bypassing pihole did not change anything.

That first try lacks credentials. At least according to the logs. Like outright missing, not simply invalid.

Did you podman also upgrade anything - like say your haproxy or nginx container?

Incidentally, I’m unclear on your topology. You referenced nextcloud:latest which would be Apache-based. Do you then have both an nginx and haproxy in front of that?

If you can, bypass keepass and try to do the WebDAV requests directly via cURL so you can see what’s going on without all the noise of the app’s error and retry handling in front of it.

Something like this should generate exactly the same GET request (and it’ll download the file to your current directory):

curl -u USERNAME:PASSWORD "https://NEXTCLOUDHOSTNAME.DOMAIN.TLD/remote.php/dav/files/iii/sync/file.kdbx"

I don’t know what happened, but at some point all sw just started working. Day or two later apps synced again, from all the devices.

About the setup: OPNsense firewall/router runs haproxy plugin terminating the ssl. It uses this container on another host as a backend.

This has worked years, and for few days there was a glitch.

Hello there.
I could fix the Problem for me. I used wireshark to see what keepass was doing and the “Client Hello” did not reach the server (or the server didn’t answer).
Because I updated the server, TLS 1.3 ONLY was activated (I can’t remember setting it). I changed it to TLS 1.2 and 1.3 and after rebooting the server (not just the services) and my PC it worked again.
I got there because a friend of mine who uses the server as well could not connect with his Outlook and got an TLS error msg.
I use Win10 with latest .NET wich should support TLS 1.3. But now it works again so I take it.
I hope this helps.

Hi !

I am having the exact same issue. Ubuntu 22.04 and Nextcloud Hub 6 (27.1.3)

Extremely annoying as there is no clear indication that there is an issue (just a little red dot at the bottom of the screen).

i am wondering how many passwords I have lost this way…

Please fix urgently :wink:


I don’t think this is a Nextcloud problem, but rather a problem with the WebDAV connection and database-type files in general, and how certain applications handle them.

Also, I think it’s generally not a good idea to edit database-type files like KeePass vaults with applications that don’t explicitly support WebDAV over a WebDAV connection.

Use the Desktop client, or the Nextcloud app on mobile to open the files. In both cases the file will be fully downloaded before the app opens it, which should avoid issues like the ones you expirienced. Or you could use an app that directly supports WebDAV, not sure if there are any KeePass apps that do support it though.

Btw. There were similar threads in the forums with people that are using Obsidian over a WebDAV connection. And when I still worked at a coroprate IT helpdesk we had tons of issues with people who copied their legacy OneNote database to SharePoint and then opened them via a WebDAV connection in Windows Explorer.

Again, use the official client apps or apps that natively support WebDAV connections to avoid issues like that.

EDIT: A more detailed explanation:

I think, the main problem is that applications which do not natively support WebDAV, and which may even save automatically every few seconds, often have no error handling for a relatively unreliable storage backend like WebDAV. These apps usually expect local storage that is always available. If the HTTP stream is interrupted because the connection drops, or times out or even if it simply takes too long to handle the request, because the webserver is busy, the data might be gone and, in the worst case, the application won’t even know that something went wrong.

It’s more complicated than that, of course, but if you want to be sure that you won’t lose any data with any application, especially with applications that use a database-like file in combination with auto-save, you shouldn’t use a WebDAV connection to work with your files (especially not the Windows client :wink: ), but instead either use applications that support WebDAV natively, because then you know that that app can at least handle errors somehow. Or even better, use the official sync client.

@bb77 I know your advice is meant well. The reason I open the keepass database directly with Keepass (or Keepass2Android) on the webdav is that I use that database with 4 people at the same time. This way everyone opens the same file. If changes are made, the chages are merged. When I do the changes localy and upload the file all the changes the other users made are gone.
And no, there is no other way to do it. I tried. The usecase I have may be uncommon, but it exist for me and this is the solution. All the other online multiaccount passwordmanagers had a lot more serious security issues in the last few years. I rather have “little” problems like this, than rely on a third party. It’s less comfortable, but much more secure. And it was the first time I had this kind of a problem with a program or app that does not support webdav natively in a long time, since nextcloud was owncloud and even before that. So every 15 or what years a little problem solving is fine. Keeps the brain swifty :wink:
Have a great day, and thanks again for the advice.

Probably just luck :wink: …as Keepass files were never designed to be edited by multiple users / clients at the same time, but in the end it mainly depends on how the client applications handle things. Of course, the storage backend itself and how the OS or clients for a particular storage backend handle things, especially if you are using some kind of network storage, will also affect how reliable things work.