Bug description
During a large initial upload (~37 GB / ~5,000 files music library), the desktop client's sync became interrupted mid-run. Afterwards the client apparently lost a subset of already-created folders from its local sync journal: on every subsequent sync run it retried MKCOL for 16 folders that already existed on the server (created by the client itself earlier in the same bulk upload), received 405 Method Not Allowed ("The resource you tried to create already exists"), flagged them as errors, and never uploaded their contents. The affected folders stayed permanently empty on the server while the client showed sync errors. The loop persisted for 11+ hours (across many sync runs and full remote-discovery cycles) with no self-healing.
Bulk uploads (PUT) stopped entirely once the loop began — only the 16 failing MKCOLs and discovery PROPFINDs remained.
Steps to reproduce
Not deterministically reproducible, but the sequence was:
- Add a large folder (~37 GB, ~5,000 files, ~840 subfolders) to a synced directory.
- Client uploads for ~6 h over a high-latency WAN route; folders are created (
MKCOL → 201) and files uploaded (PUT → 201).
- Sync gets interrupted (~19:00; exact trigger unknown — possibly app restart or connection drop on the high-latency route).
- From then on, every sync run:
MKCOL on 16 previously-created (empty) folders → 405 → error → their contents are never uploaded. Remote discovery (PROPFIND of the parents, which correctly lists the folders) does not reconcile the client's journal.
Expected behavior
On MKCOL → 405, the client should treat the folder as existing (it is listed in the parent's PROPFIND response), record it in the sync journal, and proceed to upload its contents.
Evidence (server nginx access log, sanitized)
Repeating every sync run, for hours:
10.10.0.1 - oliver [13/Aug/2026:04:10:17 +0000] "MKCOL /remote.php/dav/files/oliver/Musik/Nazareth/Love%20Hurts HTTP/1.1" 405 ...
10.10.0.1 - oliver [13/Aug/2026:04:53:49 +0000] "MKCOL /remote.php/dav/files/oliver/Musik/Keri%20Hilson/In%20A%20Perfect%20World HTTP/1.1" 405 ...
10.10.0.1 - oliver [13/Aug/2026:05:53:38 +0000] "MKCOL /remote.php/dav/files/oliver/Musik/Pink%20Floyd/The%20Wall HTTP/1.1" 405 ...
User agent: Mozilla/5.0 (Macintosh) mirall/34.0.1 (Nextcloud, macos-24.6.0 ClientArchitecture: arm64 OsArchitecture: arm64)
Upload flatline (PUTs/hour): 13:00–19:59 ≈ 600–1500/h, from 20:00 onward 0/h, while PROPFIND discovery continued normally (~1,900 requests every 2 h, all 207).
Server-side state was verified consistent: the 16 folders existed on disk and in oc_filecache with correct parent links (a PROPFIND on each parent lists them), zero children, no server log entries (sabre answers the 405 silently).
Workaround that confirms the diagnosis
Deleting the 16 empty folders server-side (occ files:delete) un-wedged the client immediately: on its next runs it re-created them (MKCOL → 201) and began uploading their contents. No client-side reset needed.
Environment
- Client: Nextcloud desktop 34.0.1, macOS (macos-24.6.0), arm64, standard sync folder
- Server: Nextcloud 34.0.2, nginx + PHP 8.3-FPM, MariaDB, Redis file locking
- Network: high-latency WAN route (VPN/proxy), which likely contributed to the interruption in step 3
Related issues
Bug description
During a large initial upload (~37 GB / ~5,000 files music library), the desktop client's sync became interrupted mid-run. Afterwards the client apparently lost a subset of already-created folders from its local sync journal: on every subsequent sync run it retried
MKCOLfor 16 folders that already existed on the server (created by the client itself earlier in the same bulk upload), received405 Method Not Allowed("The resource you tried to create already exists"), flagged them as errors, and never uploaded their contents. The affected folders stayed permanently empty on the server while the client showed sync errors. The loop persisted for 11+ hours (across many sync runs and full remote-discovery cycles) with no self-healing.Bulk uploads (
PUT) stopped entirely once the loop began — only the 16 failingMKCOLs and discoveryPROPFINDs remained.Steps to reproduce
Not deterministically reproducible, but the sequence was:
MKCOL→ 201) and files uploaded (PUT→ 201).MKCOLon 16 previously-created (empty) folders →405→ error → their contents are never uploaded. Remote discovery (PROPFINDof the parents, which correctly lists the folders) does not reconcile the client's journal.Expected behavior
On
MKCOL→ 405, the client should treat the folder as existing (it is listed in the parent'sPROPFINDresponse), record it in the sync journal, and proceed to upload its contents.Evidence (server nginx access log, sanitized)
Repeating every sync run, for hours:
User agent:
Mozilla/5.0 (Macintosh) mirall/34.0.1 (Nextcloud, macos-24.6.0 ClientArchitecture: arm64 OsArchitecture: arm64)Upload flatline (PUTs/hour):
13:00–19:59 ≈ 600–1500/h, from20:00onward0/h, whilePROPFINDdiscovery continued normally (~1,900 requests every 2 h, all207).Server-side state was verified consistent: the 16 folders existed on disk and in
oc_filecachewith correct parent links (aPROPFINDon each parent lists them), zero children, no server log entries (sabre answers the 405 silently).Workaround that confirms the diagnosis
Deleting the 16 empty folders server-side (
occ files:delete) un-wedged the client immediately: on its next runs it re-created them (MKCOL→ 201) and began uploading their contents. No client-side reset needed.Environment
Related issues
MKCOL→405 retry-loop symptom but with a different trigger (External Storage roots / virtual files); this report involves plain folders the client itself created earlier in the same sync.