[Bug]: Chunked upload via public share link fails with NotPermittedException on MOVE step (NC 33)

[potterysg-collab]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

After installing Nextcloud 33.0.0, chunked uploads via public share links fail at the final MOVE step with OCP\Files\NotPermittedException.
All chunk PUT requests succeed with HTTP 200, but when ChunkingV2Plugin attempts to assemble the chunks by moving the completed file to the target path, the MOVE request returns HTTP 500.
Impact: Files under ~100 MiB upload successfully via public share links (single PUT, no chunking). Only files exceeding the chunked upload threshold fail, making public share links effectively unusable for large file transfers. This is a critical limitation for organizations that rely on public share links to receive large files from external users.
This affects all public share links (both "File request" and links with full Read/Create/Edit/Delete permissions). Uploading the same file while logged in as an authenticated user (via /remote.php/dav/uploads/) works without issues.
This is different from #55366, which was a 400 error at the MKCOL step due to a missing nickname header and was fixed in 32.0.3. This bug occurs at the MOVE step with a NotPermittedException, even on shares that include Read permission.
Related: #52182 (feat: Enable chunked upload for public shares), #55147 (Fix public shares), #51806

Steps to reproduce

1. Create a public share link with Read + Create + Edit + Delete permissions (i.e. "Can edit")
2. Open the share link in a non-authenticated browser session
3. Upload a file larger than 100 MiB (triggers chunked upload)
4. All chunks upload successfully (PUT 200)
5. Final MOVE request fails with HTTP 500

Expected behavior

Chunked upload via public share link should complete successfully, just as it does for authenticated users.

Nextcloud Server version

33

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.4

Web server

Apache (supported)

Database engine version

PostgreSQL

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

PHP upload_max_filesize: 30G
PHP post_max_size: 30G
PHP memory_limit: 4096M
Nginx client_max_body_size: 30G

List of activated Apps

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

{
  "reqId": "XgFl7WSmZiqBMf5y8ORh",
  "level": 3,
  "time": "2026-03-24T05:19:04+00:00",
  "remoteAddr": "10.16.2.5",
  "user": "--",
  "app": "webdav",
  "method": "MOVE",
  "url": "/public.php/dav/uploads/<share-token>/web-file-upload-b9451d0f4f2bc94b/.file",
  "scriptName": "/public.php",
  "message": "Could not move /<user-id>/uploads/web-file-upload-b9451d0f4f2bc94b/.target to /<user-id>/files/<target-path>/ubuntu-20.04.5-desktop-amd64.iso",
  "version": "33.0.0.16",
  "exception": {
    "Exception": "OCP\\Files\\NotPermittedException",
    "Message": "Could not move /<user-id>/uploads/web-file-upload-b9451d0f4f2bc94b/.target to /<user-id>/files/<target-path>/ubuntu-20.04.5-desktop-amd64.iso",
    "Code": 0,
    "Trace": [
      {
        "file": "/var/www/html/apps/dav/lib/Upload/ChunkingV2Plugin.php",
        "line": 337,
        "function": "move",
        "class": "OC\\Files\\Node\\Node"
      },
      {
        "file": "/var/www/html/apps/dav/lib/Upload/ChunkingV2Plugin.php",
        "line": 222,
        "function": "completeChunkedWrite",
        "class": "OCA\\DAV\\Upload\\ChunkingV2Plugin"
      }
    ],
    "File": "/var/www/html/lib/private/Files/Node/Node.php",
    "Line": 449
  }
}

Additional info

No response