File Provider chunked upload truncates filename at #, causing repeated 404 "could not be located" errors

[apastuszak]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I have searched for it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

Uploading a file whose name contains a # character via File Provider (virtual files) on macOS fails repeatedly with a 404 error. The client's own chunked-upload URL construction truncates the filename at the #, sending a malformed path to the server — the server correctly reports that the truncated path doesn't exist, and the client retries indefinitely with the same broken request, never succeeding.

This is a client-side URL construction bug, not a server-side or reverse-proxy issue. I confirmed this by uploading the identical file, from the same Mac, to the same server, using Mountain Duck (a WebDAV client) instead of the Nextcloud desktop client — it uploaded, displayed, downloaded, and opened without any issue. This rules out the server, the WebDAV/DAV layer, and any reverse proxy in front of it as the cause, and isolates the bug to the desktop client's File Provider upload path specifically.

Steps to reproduce

• On macOS, with the account configured in File Provider (virtual files) mode, drag a file with a # in its name into a synced folder — e.g. The Nightly News Client side encryption v2 #1 (2011).cbz
• Observe the upload fail
• Observe the client automatically retry the upload with the same filename
• Observe the failure repeats indefinitely, with the menu bar icon rapidly flickering between the idle and syncing states as each retry cycles

Expected behavior

The # character should be percent-encoded (%23) when the client constructs the upload URL, exactly as any other reserved URI character. The file should upload successfully, matching the behavior of other clients (web UI upload, WebDAV clients) against the same server.

Which files are affected by this bug

Nightly News #1 (2011).cbz, Wonder Woman Historia: The Amazons #1 (2022).cbz

Operating system

macOS

Which version of the operating system you are running.

MacOS 26.6

Installation method

Official Installer for macOS 13 and later

Nextcloud Server version

33.0.6

Nextcloud Desktop Client version

34.0.1

Did this occur after an update or on a clean installation?

Clean desktop client installation

Are you using the Nextcloud Server Encryption module?

No

Are you using an external user-backend?

• Default internal user-backend
• LDAP or Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

Additional info

Relevant excerpt from the client debug log, timestamps 2026-08-05 10:51:16–10:51:36 (all other lines omitted for brevity):

2026.08.05 10:51:16.958 [info] [NextcloudKit+RemoteInterface]
Beginning chunked upload of: .../FileProviderExt/Data/tmp/__fpfsdocID(205481)_514811809_1674361599
destinationFileName: Wonder Woman Historia: The Amazons
serverUrl: https://cloud.example.com/remote.php/dav/files/USER/comics/#001 (2022).cbz
2026.08.05 10:51:25.294 [error] [Item]
Could not upload item with filename: The Nightly News #1 (2011).cbz,
received error: 404
File with name /comics/#1 (2011).cbz could not be located
received ocId: empty
2026.08.05 10:51:35.451 [error] [Item]
Could not upload item with filename: Wonder Woman Historia: The Amazons #1 (2022).cbz,
received error: 404
File with name /comics/#1 (2022).cbz could not be located
received ocId: empty

destinationFileName is already truncated (missing #1 (2022).cbz), and serverUrl shows the path broken at the # — everything before it (.../comics/) is separated from everything after it (#1 (2022).cbz), exactly what happens when a # is treated as a URL fragment delimiter instead of being percent-encoded.

This upload → 404 → retry sequence repeated at roughly 6–10 second intervals for both files over several minutes, with no eventual success.

Isolation test (Mountain Duck)

To rule out the server/proxy, I uploaded the same file (# intact) using Mountain Duck (WebDAV) against the identical Nextcloud AIO instance:

Upload succeeded
File displayed correctly in the Nextcloud web UI
File downloaded and opened successfully via the Nextcloud desktop client afterward

This confirms the server and WebDAV layer handle the # character correctly when the request is constructed properly, and the bug is isolated to how the desktop client's File Provider/chunked-upload code builds the destination URL.

Environment
Nextcloud Desktop Client version: 34.0.1 (364596d, built Aug 4 2026, Qt 6.10.2, OpenSSL 3.6.3)
Sync mode: File Provider (virtual files, suffix plugin)
OS: macOS, Darwin 25.6.0 (macOS 26 / Tahoe)
Nextcloud Server version: 34.0.2 (Nextcloud AIO / Docker)
Affected file types: at least .cbz; likely any filename containing an un-encoded #
Related issues

This appears related to, but distinct from:

nextcloud/server#57243 — closed "not planned"; filed against the server, without a client-isolation test, so the discussion focused on proxy/WebDAV theories rather than the client's own URL construction.
nextcloud/server#57353 — same, also closed "not planned," also without ruling out the client.

Given both of those were filed against nextcloud/server and closed without identifying a client-side reproduction, I'm filing this against nextcloud/desktop with the isolation test above, since the evidence points specifically at the File Provider chunked-upload code path rather than the server.

nextcloud_bugreport_sanitized.zip

[Rello]

Thank you for that report. I could reproduce it

[apastuszak]

I use Claude to help me with this. Wanted to give as much detail as possible. Let me know if you need anything else from me.

[Rello]

the first part was already enough. the error is straight forward