Please agree to the following
Summary
When using Cryptomator CLI with the WebDAV mounter, uploading a file via WebDAV succeeds with 201 Created, and the uploaded file can be read back with curl.
However, rclone fails immediately after the successful PUT, because its follow-up PROPFIND receives a 207 Multi-Status response where some requested properties return 404 Not Found while others return 200 OK.
Specifically, for an uploaded file:
displayname -> 404 Not Found
resourcetype -> 404 Not Found
getlastmodified -> 200 OK
getcontentlength -> 200 OK
This causes rclone to treat the object as missing and fail with:
Failed to copy: object not found
What software is involved?
- Operating System: Debian 13
- Cryptomator CLI: 0.6.2
- Rclone: 1.74.2
Volume Type
WebDAV (HTTP Address)
Steps to Reproduce
- Start Cryptomator CLI with the WebDAV fallback mounter, for example:
cryptomator-cli unlock \
--mounter=org.cryptomator.frontend.webdav.mount.FallbackMounter \
--volumeId=vault \
--loopbackPort=59317 \
"/tmp/test-vault"
- In another terminal, prepare a test file:
mkdir -p /tmp/rclone-webdav-src
printf 'hello from rclone webdav trace\n' > /tmp/rclone-webdav-src/test.txt
- Run rclone against the Cryptomator WebDAV endpoint:
rclone copy /tmp/rclone-webdav-src :webdav:rclone-trace-test \
--config /dev/null \
--webdav-url "http://127.0.0.1:59317/vault/" \
--webdav-vendor other \
--webdav-user cryptomator \
--webdav-pass "$(rclone obscure cryptomator)" \
--transfers 1 \
--checkers 1 \
--retries 1 \
--low-level-retries 1 \
--dump headers,bodies \
-vv
- As a control test, uploading and reading the same file with curl works:
curl -u cryptomator:cryptomator \
-X MKCOL \
"http://127.0.0.1:59317/vault/curl-control/"
curl -u cryptomator:cryptomator \
-T /tmp/rclone-webdav-src/test.txt \
"http://127.0.0.1:59317/vault/curl-control/test.txt"
curl -u cryptomator:cryptomator \
"http://127.0.0.1:59317/vault/curl-control/test.txt"
- The final curl command returns:
hello from rclone webdav trace
Expected Behavior
After a successful PUT, the uploaded file should be discoverable through PROPFIND in a way that common WebDAV clients can recognize it as an existing regular file.
For the properties requested by rclone:
<d:displayname/>
<d:getlastmodified/>
<d:getcontentlength/>
<d:resourcetype/>
the response should allow the client to determine that:
- the resource exists
- it is a regular file, not a collection
- its content length is available
- its last modified timestamp is available
Ideally, displayname, getlastmodified, getcontentlength, and resourcetype should be returned in a successful 200 OK propstat for an existing file. For a regular file, resourcetype can be returned as an empty property.
rclone should be able to complete the upload successfully instead of failing after the successful PUT with object not found.
Actual Behavior
The PUT succeeds:
PUT /vault/rclone-trace-test/test.txt HTTP/1.1
HTTP/1.1 201 Created
But the follow-up PROPFIND returns a mixed 207 Multi-Status response:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://127.0.0.1:59317/vault/rclone-trace-test/test.txt</D:href>
<D:propstat>
<D:prop>
<D:displayname/>
<D:resourcetype/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:getlastmodified>Fri, 5 Jun 2026 21:18:54 GMT</D:getlastmodified>
<D:getcontentlength>31</D:getcontentlength>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
rclone then fails with:
Failed to copy: object not found
Reproducibility
Always
Relevant Log Output
rclone:
PROPFIND /vault/rclone-trace-test HTTP/1.1
HTTP/1.1 404 Not Found
PROPFIND /vault/rclone-trace-test/ HTTP/1.1
HTTP/1.1 404 Not Found
MKCOL /vault/rclone-trace-test/ HTTP/1.1
HTTP/1.1 201 Created
PUT /vault/rclone-trace-test/test.txt HTTP/1.1
Content-Length: 31
hello from rclone webdav trace
HTTP/1.1 201 Created
PROPFIND /vault/rclone-trace-test/test.txt HTTP/1.1
HTTP/1.1 207 Multi-Status
<?xml version="1.0" encoding="UTF-8" standalone="no"?><D:multistatus xmlns:D="DAV:"><D:response><D:href>http://127.0.0.1:59317/vault/rclone-trace-test/test.txt</D:href><D:propstat><D:prop><D:displayname/><D:resourcetype/></D:prop><D:status>HTTP/1.1 404 Not Found</D:status></D:propstat><D:propstat><D:prop><D:getlastmodified>Fri, 5 Jun 2026 21:18:54 GMT</D:getlastmodified><D:getcontentlength>31</D:getcontentlength></D:prop><D:status>HTTP/1.1 200 OK</D:status></D:propstat></D:response></D:multistatus>
ERROR : test.txt: Failed to copy: object not found
NOTICE: Failed to copy: object not found
Anything else?
No response
Please agree to the following
Summary
When using Cryptomator CLI with the WebDAV mounter, uploading a file via WebDAV succeeds with
201 Created, and the uploaded file can be read back withcurl.However,
rclonefails immediately after the successfulPUT, because its follow-upPROPFINDreceives a207 Multi-Statusresponse where some requested properties return404 Not Foundwhile others return200 OK.Specifically, for an uploaded file:
This causes rclone to treat the object as missing and fail with:
What software is involved?
Volume Type
WebDAV (HTTP Address)
Steps to Reproduce
cryptomator-cli unlock \ --mounter=org.cryptomator.frontend.webdav.mount.FallbackMounter \ --volumeId=vault \ --loopbackPort=59317 \ "/tmp/test-vault"Expected Behavior
After a successful
PUT, the uploaded file should be discoverable throughPROPFINDin a way that common WebDAV clients can recognize it as an existing regular file.For the properties requested by rclone:
the response should allow the client to determine that:
Ideally,
displayname,getlastmodified,getcontentlength, andresourcetypeshould be returned in a successful200 OKpropstat for an existing file. For a regular file,resourcetypecan be returned as an empty property.rclone should be able to complete the upload successfully instead of failing after the successful
PUTwithobject not found.Actual Behavior
The
PUTsucceeds:But the follow-up
PROPFINDreturns a mixed207 Multi-Statusresponse:rclone then fails with:
Reproducibility
Always
Relevant Log Output
rclone:
Anything else?
No response