What is the problem you are having with rclone?
When authenticating to WebDav, if a password is longer than 25 characters, the http headers encode strangely and do not decode to the password I input. Important: see bottom of this for extracted data from wireshark!
Run the command 'rclone version' and share the full output of the command.
$ rclone version
rclone v1.72.1
- os/version: arch (64 bit)
- os/kernel: 6.18.5-arch1-1 (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.25.5 X:nodwarf5
- go/linking: dynamic
- go/tags: none
Which cloud storage system are you using? (eg Google Drive)
This appears to apply to any generic WebDav server, though the problem arose when testing out the “copyparty” tool.
The command you were trying to run (eg rclone copy /tmp remote:tmp)
rclone mount a-dav: /mnt/webdavtest/ --no-check-certificate
The rclone config contents with secrets removed.
Note: as I am using test strings I am not redacting this information.
[a-dav]
type = webdav
user = abcdefghijklmnopqrstuvwxyz
pass = abcdefghijklmnopqrstuvwxyz
url = http://127.0.0.1:3923
A log from the command with the -vv flag
2026/01/21 01:18:46 DEBUG : rclone: Version "v1.72.1" starting with parameters ["rclone" "mount" "a-dav:" "/mnt/webdavtest/" "--no-check-certificate" "-vv"]
2026/01/21 01:18:46 DEBUG : Creating backend with remote "a-dav:"
2026/01/21 01:18:46 DEBUG : Using config file from "/home/elle/.config/rclone/rclone.conf"
2026/01/21 01:18:46 DEBUG : found headers:
2026/01/21 01:18:46 INFO : webdav root '': poll-interval is not supported by this remote
2026/01/21 01:18:46 NOTICE: webdav root '': --vfs-cache-mode writes or full is recommended for this remote as it can't stream
2026/01/21 01:18:46 DEBUG : webdav root '': Mounting on "/mnt/webdavtest/"
2026/01/21 01:18:46 DEBUG : Root:
2026/01/21 01:18:46 DEBUG : >Root: node=/, err=<nil>
2026/01/21 01:18:46 DEBUG : Statfs:
2026/01/21 01:18:46 DEBUG : Statfs:
2026/01/21 01:18:46 ERROR : webdav root '': Statfs failed: <pre>authenticate
URL:: 401 Unauthorized
2026/01/21 01:18:46 DEBUG : >Statfs: stat={Blocks:4503599627370495 Bfree:4503599627370495 Bavail:4503599627370495 Files:1000000000 Ffree:1000000000 Bsize:4096 Namelen:255 Frsize:4096}, err=<nil>
2026/01/21 01:18:46 DEBUG : >Statfs: stat={Blocks:274877906944 Bfree:274877906944 Bavail:274877906944 Files:1000000000 Ffree:1000000000 Bsize:4096 Namelen:255 Frsize:4096}, err=<nil>
^C2026/01/21 01:18:50 INFO : Signal received: interrupt
2026/01/21 01:18:50 NOTICE: /mnt/webdavtest/: Unmounted rclone mount
2026/01/21 01:18:50 INFO : Exiting...
Naturally, this is a simple 401 error. Not much to see here. However, booting up wireshark and monitoring the connection shows this interesting snippet:
Authorization: Basic YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo6cWsL\r\n
Decoding this string gives us a wrong username:password combo:
abcdefghijklmnopqrstuvwxyz:qk\v (note that \v is actually character 0x000b, vertical tabulation character. it’s basically junk.)
If I perform the same actions as above with a single letter shorter password, I get something more valid:
Authorization: Basic YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo6YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eQ==\r\n
which decodes to: abcdefghijklmnopqrstuvwxyz:abcdefghijklmnopqrstuvwxy, a valid http basic auth header.
Furthermore in my testing, the username length did not appear to matter, I attempted with a length up to 62 characters; The username always decodes fine, but the password portion of the auth string does not encode at 26 characters or more.
Other WebDAV tools such as KDE dolphin send a header that decodes properly even at a length of 62+ characters for each:
Authorization: Basic YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXpBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWjEyMzQ1Njc4OTA6YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXpBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWjEyMzQ1Njc4OTA=\r\n
Decodes to:
Credentials: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890:abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890
Per my understanding of http headers, for the most part there is no max limit set by the standard, but some tools such as apache include guidance or parameters of 255 max chars for both username and password. 25 characters seems short for a maximum length of a field like password.
It’s worth noting that my intent is to use this feature over https and I am experiencing an apparently similar issue there, but I lack the skill with wireshark to decode https traffic at this time. I have no reason, based on my understanding of the above, to believe that http vs https would make a difference in this situation.
In the interest of full disclosure, here is the link to the github where this issue was first reported with copyparty and my initial tests.