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.