nextcloud / nextcloud/files_lock

LOCK request fails with NotFoundException for paths containing special characters (umlauts) after URL-decoding

Open
#1,222 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

0. Needs triage bug
Dominant language
JavaScript
Stars
39
Forks
10
Avg merge
1d 11h
Merged PRs (30d)
48

Description

Description

LOCK requests via WebDAV consistently fail with OCP\Files\NotFoundException for file paths containing special characters (German umlauts in our case), even though the file exists and can be read/written normally.

Environment

  • Nextcloud version: 34.0.2.1
  • files_lock version: 34.0.1
  • Client: Nextcloud Desktop Client (mirall) 33.0.5, macOS (arm64)
  • PHP: (bitte eure PHP-Version ergänzen)

Steps to reproduce

  1. Create/use a file with a special character (umlaut) in the folder or file name, e.g.:
    Projects/_TEAM_BÜRO/___Cover_Letter_Template .docx
  2. Open the file via the desktop client (triggers a WebDAV LOCK request)
  3. Observe the server log

Expected behavior

The file should be locked successfully, same as for files without special characters.

Actual behavior

Server throws OCP\Files\NotFoundException and the request fails with an uncaught exception. This has been reproduced multiple times, on different files, all with special characters (umlauts) in the path.

Log excerpt

{
  "app": "webdav",
  "method": "LOCK",
  "url": "/remote.php/dav/files/<user>/Projects/_TEAM_B%C3%9CRO/___Cover_Letter_Template%20.docx",
  "message": "/<user>/files/Projects/_TEAM_BÜRO/___Cover_Letter_Template .docx",
  "exception": {
    "Exception": "OCP\\Files\\NotFoundException",
    "Message": "/<user>/files/Projects/_TEAM_BÜRO/___Cover_Letter_Template .docx",
    "Trace": [
      {"file": ".../lib/private/Files/Node/LazyFolder.php", "line": 141, "function": "get", "class": "OC\\Files\\Node\\Root"},
      {"file": ".../apps/files_lock/lib/Service/FileService.php", "line": 119, "function": "get", "class": "OC\\Files\\Node\\LazyFolder"},
      {"file": ".../apps/files_lock/lib/DAV/LockPlugin.php", "line": 192, "function": "getFileFromAbsoluteUri", "class": "OCA\\FilesLock\\Service\\FileService"},
      {"file": ".../3rdparty/sabre/event/lib/WildcardEmitterTrait.php", "line": 89, "function": "httpLock", "class": "OCA\\FilesLock\\DAV\\LockPlugin"}
    ]
  }
}

Additional context

  • The file itself opens, edits, and saves correctly outside of the LOCK mechanism (no data loss).
  • Only the lock acquisition fails — the practical impact is a missing collision-protection warning when multiple users edit the same file concurrently.
  • Reproduced on at least two different files/folders, both containing umlauts (Ü, ö) in the path, suggesting the issue lies in how FileService::getFileFromAbsoluteUri() resolves URL-decoded paths with non-ASCII characters, rather than being specific to one file.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in apps/files_lock/lib/Service/FileService.php, especially getFileFromAbsoluteUri(), and trace how the LOCK request reaches it through apps/files_lock/lib/DAV/LockPlugin.php. Reproduce the WebDAV LOCK request with the umlaut-containing path and verify that the existing file is resolved and locked without OCP\Files\NotFoundException.

Written by the indexing model from the issue text.

Assessment

Tech stack
php
Domain
backend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.