WebDAV + rclone fails with 401 Unauthorized when using 2FA (app password)

Hi Ralf,

Thank you for your suggestion and for sharing your workaround — much appreciated.

I tested your approach using a fresh application password and verified the Base64 encoding. Unfortunately, I was not able to reproduce your results. Both rclone (v1.70.3) and curl return HTTP 401 when using the manual Authorization header, regardless of whether I use the base Userstore path or include my full name in the URL.

For reference, I also tested both my primary login (larsc@inetpub.dk) and the original mailbox.org account (60877727@mailbox.org), with identical results.

At this point it does seem like there may be some account-specific differences or inconsistencies in how mailbox.org handles WebDAV authentication — especially with 2FA and app passwords involved.

That said, your workaround was definitely worth testing, and it’s reassuring to know that others have run into similar issues.

Thanks again for taking the time to share your findings.

Best regards,
Lars

Sorry for the late reply.

It should work. Even if 2FA is enabled. And it still works for me after reenabling 2FA.

Webdav with basic authentication (RFC 7617 iff I remember right) uses a base64 encoded "username:password". There is no knowledge about 2FA in webdav, the protocol is at least 10 maybe 20 years old. 2FA usually works by not accepting the username:password combination any more for webdav.

Maybe you want to send me some debug output of your "rclone lsd" command to ralf.herrmann@mailbox.org, like this one.

ralf@fenris:~ # rclone -vv lsd mailbox.org:
2026/04/01 22:43:54 DEBUG : Setting --config "/etc/backup/rclone.conf" from environment variable RCLONE_CONFIG="/etc/backup/rclone.conf"
2026/04/01 22:43:54 DEBUG : rclone: Version "v1.73.3" starting with parameters ["rclone" "-vv" "lsd" "mailbox.org:"]
2026/04/01 22:43:54 DEBUG : Creating backend with remote "mailbox.org:"
2026/04/01 22:43:54 DEBUG : Using config file from "/etc/backup/rclone.conf"
2026/04/01 22:43:54 DEBUG : found headers: Authorization,Basic ***SECRET***
-1 2026-03-27 21:10:14 -1 Documents
-1 2021-11-20 02:52:43 -1 Music
-1 2025-12-29 20:54:06 -1 Pictures
-1 2025-08-29 18:04:55 -1 Videos
2026/04/01 22:43:54 DEBUG : 5 go routines active

If you post the debug output here take care to remove the base64 encoded string with your authentication!

Hi Ralf,

Thank you again for your input and for taking the time to share your working setup.

I went through a clean and systematic test to make sure I am not missing anything obvious. Below is exactly what I did.

Environment

* rclone v1.70.3 (Debian 12)

* No custom environment variables (RCLONE_* not set)

* Default config location: ~/.config/rclone/rclone.conf

* rclone binary: /usr/bin/rclone (no alias or wrapper)

Test setup

1. Enabled 2FA on the account

2. Created a fresh application password (type: Drive Sync app)

3. Verified the app password is tied to:

* Brugernavn: larsc@inetpub.dk ("Brugernavn" is danish for username)

4. Generated Base64 manually:

echo -n 'larsc@inetpub.dk:xxxx-xxxx-xxxx-xxxx' | base64

5. Also tested with original mailbox account:

echo -n '60877727@mailbox.org:xxxx-xxxx-xxxx-xxxx' | base64

rclone configuration (header-based, as suggested)

Tested four variants:

* /Userstore/

* /Userstore/Lars%20Christensen/

* both usernames (custom domain + original mailbox.org)

Example:

[mailbox-a0]

type = webdav

url = https://dav.mailbox.org/servlet/webdav.infostore/Userstore/

vendor = other

headers = Authorization,Basic <base64>

Result (all variants)

401 Unauthorized

Direct curl test (to remove rclone entirely)

curl -i -X PROPFIND \

-H "Depth: 1" \

-H "Authorization: Basic <base64>" \

"https://dav.mailbox.org/servlet/webdav.infostore/Userstore/"

Also tested with:

.../Userstore/Lars%20Christensen/

Same result in all cases:

HTTP/2 401

www-authenticate: Basic realm="OX WebDAV"

Observations

* This reproduces the issue completely outside rclone

* Both username formats fail

* Both URL variants fail

* App password is freshly generated and confirmed

So at this point, it looks less like a client issue and more like:

* account-specific behavior, or

* something related to 2FA/app password handling on mailbox.org’s WebDAV backend

One notable difference from your setup:

* I am using a custom domain login ([larsc@inetpub.dk](mailto:larsc@inetpub.dk)), even though the original mailbox account is [60877727@mailbox.org](mailto:60877727@mailbox.org)

That may or may not be relevant.

In any case, your workaround was definitely worth testing, and I appreciate you sharing it — it helped rule out a lot of variables.

Best regards,

Lars

Hi Ralf,

Thank you for your reply.

I understand your point regarding using a WebDAV-specific application password. However, in my account I do not have an option for a "WebDAV client" when creating an application password.

The available options are:

Client for calendar and address book

CalDAV client

Drive Sync app

Exchange ActiveSync

Given that WebDAV is the protocol used for accessing OX Drive, the "Drive Sync app" appears to be the only relevant option for file access.

I therefore used a freshly generated "Drive Sync app" password for all tests. Regards, Lars.

Hi Lars,

that's curios - but maybe just a wrong translation. You're using Dansk language, aren't you?

If we compare the screenshots of German, English and Dansk options we see some anomaly in the second option. In German it is "WebDAV-Client", in English "WebDAV Client" but in Danish "Klient til CalDAV". Any other option is the same (beside localisation differences).

So I would assume you need to set up an application password of type "Klient til CalDAV".

If this is working you may want to file a bug report to mailbox.org to fix the Danish localisation.

With kind regards, Ralf

Hi Ralf,

thank you for sticking with this – your observation about the Danish translation turned out to be exactly right.

The option labelled “Klient til CalDAV” in the Danish UI does indeed work as a WebDAV application password. Using that, I was finally able to authenticate successfully against:

https://dav.mailbox.org/servlet/webdav.infostore/Userstore/

A direct PROPFIND test with curl returned a valid 207 Multi-Status, confirming that authentication and access were working.

From there, the remaining issue turned out to be on the client side. rclone consistently failed or hung unless I disabled HTTP keep-alives:

--disable-http-keep-alives

With that in place, I now have a fully working setup using rclone bisync between Mailbox.org Drive and a local directory.

Final working setup:

• WebDAV endpoint:
  /servlet/webdav.infostore/Userstore/Lars%20Christensen/
• Application password type:
  “Klient til CalDAV” (Danish UI)
• rclone:
  Requires --disable-http-keep-alives
• Sync mode:
  rclone bisync with --size-only

Test results:

• Authentication: OK (curl + WebDAV)
• File listing: OK
• Full initial sync (~500 MB / 2300 files): OK
• Handles Danish characters (æ, ø, å) and spaces without issues

So the root causes were:

1. Misleading Danish translation (CalDAV vs WebDAV)
2. HTTP connection handling between rclone and mailbox.org

Your hint about the translation mismatch was the key that unlocked the rest – without that, I would not have revisited the application password type.

Thanks again for your help and persistence.

Kind regards,
Lars

Glad to hear and an interesting finding about the --disable-http-keep-alives. Didn't expect this one to interfere. Iff I get some time I will try to check it out.

Happy syncing ;-)