Welcome to the mailbox user forum

New Topic

mailbox user forum Topic Problem Data Synchronization: Setup

Category Data Synchronization: Setup

Tags rclone

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

Lars Christensen shared this problem ago

Published

I’m trying to set up synchronization between Mailbox.org Drive and a local directory using rclone on Linux.

After enabling 2FA on my Mailbox.org account, I created a separate app password specifically for rclone, but I’m unable to authenticate via WebDAV.

Setup:

* OS: Debian 12

* rclone version: 1.70.3

rclone config:

* Storage type: webdav

* WebDAV vendor: other

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

* User: name@custom-domain.dk

* Password: app password (format: xxxx-xxxx-xxxx-xxxx)

Test command:

rclone ls mailbox:

Result:

ERROR : error listing: couldn't list files: 401 Unauthorized

NOTICE: Failed to ls with 2 errors: last error was: couldn't list files: 401 Unauthorized

Notes:

* The app password was created after enabling 2FA

* Login via web interface works as expected

* This setup worked previously before enabling 2FA (using normal password)

* No special headers or advanced config used in rclone

Questions:

1. Does Mailbox.org WebDAV support app passwords when 2FA is enabled?

2. Is the WebDAV endpoint (`/servlet/webdav.infostore/Userstore`) still correct for this use case?

3. Are there any known limitations or additional requirements when using WebDAV with 2FA-enabled accounts?

4. Has anyone successfully used rclone with Mailbox.org Drive and 2FA enabled?

Any guidance or working configuration examples would be appreciated.

Thanks in advance.

The same problem 0

Replies (1)

Ralf Herrmann ●

While not using 2FA I've run into the same problem and solved it by tearing my hair out.

rclone v1.73.3

os/version: opensuse-tumbleweed 20260327 (64 bit)
os/kernel: 6.19.9-1-default (x86_64)

Looks like either rclone (and even curl used for testing) has an error... or the mailbox.org side. So I've had to skip the standard authentication.

[mailbox.org]
type = webdav
url = https://dav.mailbox.org/servlet/webdav.infostore/Userstore/Ralf%20Herrmann/
vendor = other
# use echo -n 'user@mailbox.org:password' | base64 to encode your own string like my example dXNIck...
# use an app password, please: settings -> all settings -> security -> application passwords
headers = Authorization,Basic dXNlckBtYWlsYm94Lm9yZzpwYXNzd29yZA==

Last but not least we get:

ralf@fenris:~ # rclone lsd mailbox.org:
-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

Hurray!

P.S.: If you start testing, you may start with url = https://dav.mailbox.org/servlet/webdav.infostore/Userstore/ It's valid and should NOT give you an http 401 FORBIDDEN.

Reply URL

Lars Christensen ●

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

URL

Ralf Herrmann ●

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!

URL

Lars Christensen ●

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 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

URL