Nextcloud 31 – users without delete rights can’t rename folders (403 MOVE denied)

ℹ️ Support
, ,
1
Support intro

Sorry to hear you’re facing problems. :slightly_frowning_face:

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 31.0.9
  • Operating system and version (e.g., Ubuntu 24.04):
    • Ubuntu 24.04
  • Web server and version (e.g, Apache 2.4.25):
    • 2.4.58
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • None
  • PHP version (e.g, 8.3):
    • 8.3.6
  • Is this the first time you’ve seen this error? (Yes / No):
    • No
  • When did this problem seem to first start?
    • After upgrading from v29
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • Manual archive extraction (download + unpack, standard config) - PCT container
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • No

Summary of the issue you are facing:

After migrating from a v29 instance to a clean v31.0.9 build, users without delete permission can no longer rename files or folders inside Group Folders (or regular shares using granular ACLs).

When creating a .txt or a folder through the web UI the name will stay the same, but can’t rename once it’s been created - even though create, read & update permissions are applied.

However from a desktop client it temporarily renames it (note, not talking about post creation rename, it’s when you create the folder / file and give it a name before it even gets created) but when it syncs with the server, it reverse back - i.e New Folder, New Text Document.txt, etc.

Granting delete permission fixes it immediately - but that undermines our entire rights model.

This used to work in v29 and earlier, upgraded on a staging server to V32.0.0 and still reproduceable. This is happening on our prod server, but same on a test one I spun up to try and recreate the issue - so it’s not isolated.

Steps to replicate it (hint: details matter!):

  1. Create a Group Folder (or shared folder).

  2. Assign a user read + create + update permissions, but no delete.

  3. On a Windows PC running the Nextcloud desktop client (3.17.2), inside the synced folder: Create a new folder and name it, or rename an existing one.

  4. Wait for the client to sync.

Control tests

  1. Create in web interface (.txt or folder) –> name persists.
  2. Create/rename outside the sync folder (e.g., Desktop), then copy into the synced folder –> name persists.
  3. Grant delete permissions –> rename works normally.

Log entries

Nextcloud

Please provide the log entries from your Nextcloud log that are generated during the time of problem (via the Copy raw option from Administration settings->Logging screen or from your nextcloud.log located in your data directory). Feel free to use a pastebin/gist service if necessary.

Sabre\DAV\Exception\Forbidden: files/test/Test Share/CRA/New folder cannot be deleted
  at apps/dav/lib/Connector/Sabre/FilesPlugin.php line 209
  ...

Web Browser

If the problem is related to the Web interface, open your browser inspector Console and Network tabs while refreshing (reloading) and reproducing the problem. Provide any relevant output/errors here that appear.

PASTE

Web server / Reverse Proxy

The output of your Apache/nginx/system log in /var/log/____:

192.168.x.x - user [09/Oct/2025:11:23:02 +0200]
"MOVE /remote.php/dav/files/test/Test%20Share/CRA/New%20folder HTTP/1.1" 403 727

Configuration

Nextcloud

The output of occ config:list system or similar is best, but, if not possible, the contents of your config.php file from /path/to/nextcloud is fine (make sure to remove any identifiable information!):

{
  "version": "31.0.9.1",
  "dbtype": "mysql",
  "filelocking.enabled": true,
  "memcache.local": "\\OC\\Memcache\\Redis",
  "memcache.locking": "\\OC\\Memcache\\Redis"
}

Apps

The output of occ app:list (if possible).

Enabled:
 - files_sharing: 1.23.1
 - groupfolders: 19.1.7
 - files: 2.3.1
 - files_trashbin: 1.21.0
 - files_versions: 1.24.0
 - dav: 1.33.0

Client environment

  • OS: Windows 10/11

  • Nextcloud desktop client: 3.17.2 (20250916)

Browser

N/A — issue does not occur in the web interface.

Notes / Workarounds

  • Creating or renaming outside the sync folder (e.g., Desktop → copy into Nextcloud) works fine.

  • Granting delete permission fixes the problem but re-introduces risk of accidental mass deletes/moves.

  • Server log clearly shows MOVE denied (403) when delete is missing — a regression from v29.

Request

Please re-allow rename operations for users with create + update rights, or introduce a dedicated rename permission decoupled from delete/move.
This change broke a safe, long-standing workflow in multi-user deployments relying on strict ACLs.

1 Like
2