Upgrade StorageKoofr WebDAV stopped syncing: HTTP 405 on PUT (Report ID 54288118)
Report ID: 54288118
Hello,
My Zotero attachment syncing with Koofr WebDAV had been working previously, but it stopped working on 13 November 2026.
The initial error occurred during an actual attachment upload: Zotero reported that the WebDAV server returned HTTP 405 for a PUT request to an attachment ZIP file. Clicking “Verify Server” also fails.
Environment:
- Zotero 10.0.8 (x64)
- Windows 11, build 26100
- Koofr’s own storage, not a connected OneDrive or another external storage provider
- WebDAV base URL: https://app.koofr.net/dav/Koofr
- The problem also occurs in Troubleshooting Mode. The debug log shows safeMode => true and the Translate for Zotero extension disabled.
Steps to reproduce:
1. Open Settings → Account → File Syncing.
2. With Koofr WebDAV configured, click “Verify Server”.
3. Verification fails with HTTP 405.
Relevant debug output:
Two verification attempts in the latest log show the same sequence. Account details have been omitted:
OPTIONS /dav/Koofr/zotero/
→ 200
PROPFIND /dav/Koofr/zotero/
→ 207
GET /dav/Koofr/zotero/nonexistent.prop
→ 404
PUT /dav/Koofr/zotero/zotero-test-file.prop
→ 405 Method Not Allowed
WebDAV verification failed
File sync failed for library 1
The PUT request sends a test file containing only a single space.
The PROPFIND response contains a 404 status for the getcontentlength property, but Zotero continues past that response and the expected 404 for nonexistent.prop. The verification then fails at the PUT request.
I also saw an HTTP 404 verification error during an earlier attempt, but the latest debug log reproduces the PUT 405 failure twice.
Zotero data syncing completes its check before the file-sync phase fails. The latest logged attempts were around 06:30 UTC on 13 November 2026.
Could you please review the report and advise whether this suggests a Zotero-side issue, or whether I should ask Koofr to investigate the rejected PUT requests? I can provide a Debug ID for a verification attempt if needed.
Thank you.
Hello,
My Zotero attachment syncing with Koofr WebDAV had been working previously, but it stopped working on 13 November 2026.
The initial error occurred during an actual attachment upload: Zotero reported that the WebDAV server returned HTTP 405 for a PUT request to an attachment ZIP file. Clicking “Verify Server” also fails.
Environment:
- Zotero 10.0.8 (x64)
- Windows 11, build 26100
- Koofr’s own storage, not a connected OneDrive or another external storage provider
- WebDAV base URL: https://app.koofr.net/dav/Koofr
- The problem also occurs in Troubleshooting Mode. The debug log shows safeMode => true and the Translate for Zotero extension disabled.
Steps to reproduce:
1. Open Settings → Account → File Syncing.
2. With Koofr WebDAV configured, click “Verify Server”.
3. Verification fails with HTTP 405.
Relevant debug output:
Two verification attempts in the latest log show the same sequence. Account details have been omitted:
OPTIONS /dav/Koofr/zotero/
→ 200
PROPFIND /dav/Koofr/zotero/
→ 207
GET /dav/Koofr/zotero/nonexistent.prop
→ 404
PUT /dav/Koofr/zotero/zotero-test-file.prop
→ 405 Method Not Allowed
WebDAV verification failed
File sync failed for library 1
The PUT request sends a test file containing only a single space.
The PROPFIND response contains a 404 status for the getcontentlength property, but Zotero continues past that response and the expected 404 for nonexistent.prop. The verification then fails at the PUT request.
I also saw an HTTP 404 verification error during an earlier attempt, but the latest debug log reproduces the PUT 405 failure twice.
Zotero data syncing completes its check before the file-sync phase fails. The latest logged attempts were around 06:30 UTC on 13 November 2026.
Could you please review the report and advise whether this suggests a Zotero-side issue, or whether I should ask Koofr to investigate the rejected PUT requests? I can provide a Debug ID for a verification attempt if needed.
Thank you.
-
dstillman Zotero TeamThat's a 405 Method Not Allowed error from the WebDAV server. You'd have to ask them.