[Bug]: Cannot assign labels to folders and files - NextCloud 34.0.4

[PeopleInside]

Bug description

After upgrading to NextCloud 34.0.4 when I try to assign a label to a folder or a file I get the error: Impossible apply edits on the labels (tis message is translated in English from Italian).

Steps to reproduce

1. Apply a label to a folder or a file
2. An error message is showed

Expected behavior

No errors and label assigned

Nextcloud Server version

34

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.5

Web server

Apache (supported)

Database engine version

MariaDB

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

Updated from a MINOR version (ex. 32.0.1 to 32.0.2)

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

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "nextcloud.domain.ext"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "34.0.4.1",
        "enable_push_notifications": false,
        "overwrite.cli.url": "https:\/\/nextcloud.domain.ext\/folder",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "mail_smtpmode": "smtp",
        "mail_smtpsecure": "ssl",
        "mail_sendmailmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "465",
        "mail_smtpauth": true,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "simpleSignUpLink.shown": false,
        "maintenance": false,
        "theme": "",
        "loglevel": 2,
        "filesystem_check_changes": 1,
        "maintenance_window_start": 1,
        "trashbin_retention_obligation": "7,8",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "app_install_overwrite": [
            "passwords",
            "theming_customcss"
        ],
        "forbidden_filename_basenames": [
            "con",
            "prn",
            "aux",
            "nul",
            "com0",
            "com1",
            "com2",
            "com3",
            "com4",
            "com5",
            "com6",
            "com7",
            "com8",
            "com9",
            "com\u00b9",
            "com\u00b2",
            "com\u00b3",
            "lpt0",
            "lpt1",
            "lpt2",
            "lpt3",
            "lpt4",
            "lpt5",
            "lpt6",
            "lpt7",
            "lpt8",
            "lpt9",
            "lpt\u00b9",
            "lpt\u00b2",
            "lpt\u00b3"
        ],
        "forbidden_filename_characters": [
            "<",
            ">",
            ":",
            "\"",
            "|",
            "?",
            "*",
            "\\",
            "\/"
        ],
        "forbidden_filename_extensions": [
            " ",
            ".",
            ".filepart",
            ".part"
        ],
        "updater.secret": "***REMOVED SENSITIVE VALUE***"
    }
}

List of activated Apps

Enabled:
  - activity: 7.0.0
  - appstore: 1.0.0
  - bruteforcesettings: 7.0.0
  - calendar: 6.5.4
  - circles: 34.0.0
  - cloud_federation_api: 1.18.0
  - comments: 1.24.0
  - contacts: 8.8.1
  - contactsinteraction: 1.15.0
  - dashboard: 7.14.0
  - dav: 1.40.0
  - federatedfilesharing: 1.24.0
  - federation: 1.24.0
  - files: 2.6.0
  - files_automatedtagging: 5.0.0
  - files_downloadlimit: 5.2.0
  - files_lock: 34.0.1
  - files_pdfviewer: 7.0.0
  - files_reminders: 1.7.0
  - files_retention: 5.0.0
  - files_sharing: 1.26.0
  - files_trashbin: 1.24.0
  - files_versions: 1.27.0
  - firstrunwizard: 7.0.0-dev.0
  - logreader: 7.0.0
  - lookup_server_connector: 1.22.0
  - mail: 5.11.5
  - nextcloud_announcements: 6.0.0
  - notes: 6.0.2
  - notifications: 7.0.0-dev.1
  - oauth2: 1.22.0
  - office: 1.0.0
  - password_policy: 6.0.0-dev.0
  - passwords: 2026.7.20
  - photos: 7.0.0
  - privacy: 6.0.0-dev.1
  - profile: 1.3.0
  - provisioning_api: 1.24.0
  - recommendations: 7.0.0
  - related_resources: 5.0.0-dev.0
  - richdocuments: 11.1.1
  - richdocumentscode: 26.4.303
  - serverinfo: 6.0.0
  - settings: 1.17.0
  - sharebymail: 1.24.0
  - spreed: 24.0.5
  - support: 6.0.0
  - survey_client: 6.0.0-dev.0
  - suspicious_login: 12.0.0-dev.0
  - systemtags: 1.24.0
  - text: 8.0.0
  - theming: 2.9.0
  - theming_customcss: 1.22.0
  - twofactor_backupcodes: 1.23.0
  - twofactor_totp: 16.0.0
  - twofactor_webauthn: 2.7.1
  - updatenotification: 1.24.0
  - user_status: 1.14.0
  - viewer: 7.0.0-dev.0
  - weather_status: 1.14.0
  - webhook_listeners: 1.6.0
  - workflowengine: 2.16.0
Disabled:
  - admin_audit: 1.24.0
  - app_api: 34.0.0 (installed 32.0.0)
  - encryption: 2.22.0
  - files_external: 1.26.0
  - twofactor_nextcloud_notification: 8.0.0 (installed 3.10.0)
  - user_ldap: 1.25.0

Nextcloud Signing status

Nextcloud Logs

Additional info

No response

[PeopleInside]

Additional debugging information

I've done some further investigation and can provide more technical details to help triage this regression.

Network-level behavior

Using the browser DevTools (Network tab), I can see that when I try to assign a label to a file or folder, the frontend correctly issues a WebDAV PROPPATCH request to:

PROPPATCH /remote.php/dav/systemtags/{tag_id}/files

The server responds with HTTP 403 Forbidden, and the frontend surfaces the error:

[ERROR] systemtags: Failed to apply tags
error: Error: Invalid response: 403

This is a regression: the exact same workflow worked flawlessly on the previous minor version, immediately before the 34.0.4 upgrade.

Server-side logs are silent

This is the most suspicious part:

• Nextcloud log (nextcloud.log / Admin → Logging): No entry is generated at all when the 403 occurs. The request seems to be rejected internally without any exception being logged.
• Apache error log: No error is recorded for the PROPPATCH request either. The only entries I see are the expected, correct denials for direct access to /data/.ncdata and scanner probes on unrelated phpinfo.php.* files — nothing related to systemtags or remote.php/dav.

This strongly suggests the 403 is being generated silently inside the systemtags / dav app code path in 34.0.4, rather than by a server configuration or WAF rule.

Environment

• Nextcloud: 34.0.4.1 (regression appeared exactly after the upgrade from the previous minor)
• OS: Debian/Ubuntu
• PHP: 8.5
• Web server: Apache (no reverse proxy, no Cloudflare, no ModSecurity)
• Database: MariaDB
• Installation method: classic archive via control panel

Relevant enabled apps (versions from 34.0.4)

• systemtags: 1.24.0
• files_automatedtagging: 5.0.0
• files_retention: 5.0.0
• workflowengine: 2.16.0
• dav: 1.40.0

Impact

This is a blocking issue for users who rely on labels to drive automated file retention/expiration via files_retention + files_automatedtagging. Without the ability to manually assign labels, the whole automated expiration workflow is broken.

What I have NOT tried (to avoid making the situation worse)

To keep the production environment stable while waiting for a fix, I have deliberately avoided:

• Disabling files_automatedtagging / files_retention / workflowengine
• Manually changing file ownership or permissions
• Editing the database

I am willing to run additional read-only diagnostics (e.g. occ commands, specific curl requests, log level changes) if that helps the team reproduce the issue.

Suggested areas to investigate

Given the silent 403, the regression likely lives in one of these areas introduced or touched in 34.0.4:

1. Permission/capability checks inside apps/systemtags/lib/Controller/ or the DAV plugin handling PROPPATCH on /systemtags/{id}/files.
2. A change in how workflowengine / files_automatedtagging hooks interact with manual tag assignment.
3. A stricter CSRF or app-password check on the systemtags DAV endpoint that the web frontend is no longer satisfying.

Thank you for looking into this.

[jum]

I can add that I see the same and get this in my logs if I attempt to assign an admin defined tag, and I am a genuine admin user.

{
  "insertId": "z8xwevg120idt5",
  "jsonPayload": {
    "version": "33.0.9.1",
    "level": 0,
    "scriptName": "/remote.php",
    "method": "PROPPATCH",
    "CustomMessage": "You don’t have permissions to update tags",
    "exception": "{\"class\":\"Sabre\\DAV\\Exception\\Forbidden\",\"message\":\"You don’t have permissions to update tags\",\"code\":0,\"file\":\"/var/www/html/apps/dav/lib/SystemTag/SystemTagPlugin.php:454\",\"trace\":\"#0 /var/www/html/3rdparty/sabre/dav/lib/DAV/PropPatch.php(288): OCA\\DAV\\SystemTag\\SystemTagPlugin->{closure:OCA\\DAV\\SystemTag\\SystemTagPlugin::handleUpdateProperties():415}(Array)\\n#1 /var/www/html/3rdparty/sabre/dav/lib/DAV/PropPatch.php(227): Sabre\\DAV\\PropPatch->doCallBackMultiProp(Array, Object(Closure))\\n#2 /var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php(1264): Sabre\\DAV\\PropPatch->commit()\\n#3 /var/www/html/3rdparty/sabre/dav/lib/DAV/CorePlugin.php(373): Sabre\\DAV\\Server->updateProperties('systemtags/7/fi...', Array)\\n#4 /var/www/html/3rdparty/sabre/event/lib/WildcardEmitterTrait.php(89): Sabre\\DAV\\CorePlugin->httpPropPatch(Object(Sabre\\HTTP\\Request), Object(Sabre\\HTTP\\Response))\\n#5 /var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php(472): Sabre\\DAV\\Server->emit('method:PROPPATC...', Array)\\n#6 /var/www/html/apps/dav/lib/Connector/Sabre/Server.php(212): Sabre\\DAV\\Server->invokeMethod(Object(Sabre\\HTTP\\Request), Object(Sabre\\HTTP\\Response))\\n#7 /var/www/html/apps/dav/lib/Server.php(432): OCA\\DAV\\Connector\\Sabre\\Server->start()\\n#8 /var/www/html/apps/dav/appinfo/v2/remote.php(25): OCA\\DAV\\Server->exec()\\n#9 /var/www/html/remote.php(151): require_once('/var/www/html/a...')\\n#10 {main}\"}",
    "instance": {
      "id": "redacted",
      "zone": "redacted"
    },
    "tag": "nextcloud",
    "Line": 454,
    "container": {
      "created": "2026-09-13T14:15:06.804149005Z",
      "imageId": "sha256:0571e212fb9735dd23d425f66c7688cd0e327c8ab90663771dae48b40f6fb228",
      "imageName": "nextcloud:33-fpm-alpine",
      "name": "/nextcloud",
      "id": "ed9d1da30b90d31d8eb4405b32795a0b3ef6939b64d8e9c952fc5d74ed3a1c8a"
    },
    "Message": "You don’t have permissions to update tags",
    "Exception": "Sabre\\DAV\\Exception\\Forbidden",
    "File": "/var/www/html/apps/dav/lib/SystemTag/SystemTagPlugin.php",
    "Code": 0,
    "remoteAddr": "2a0d:3344:20a9:ea10:b97a:8aa:4617:e8d9",
    "Trace": [
      {
        "args": [
          "*** sensitive parameters replaced ***"
        ],
        "class": "OCA\\DAV\\SystemTag\\SystemTagPlugin",
        "file": "/var/www/html/3rdparty/sabre/dav/lib/DAV/PropPatch.php",
        "type": "->",
        "function": "{closure:OCA\\DAV\\SystemTag\\SystemTagPlugin::handleUpdateProperties():415}",
        "line": 288
      },
      {
        "args": [
          [
            "{http://nextcloud.org/ns}object-ids"
          ],
          {
            "__class__": "Closure"
          }
        ],
        "class": "Sabre\\DAV\\PropPatch",
        "file": "/var/www/html/3rdparty/sabre/dav/lib/DAV/PropPatch.php",
        "function": "doCallBackMultiProp",
        "type": "->",
        "line": 227
      },
      {
        "function": "commit",
        "line": 1264,
        "type": "->",
        "class": "Sabre\\DAV\\PropPatch",
        "file": "/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php",
        "args": []
      },
      {
        "args": [
          "*** sensitive parameters replaced ***"
        ],
        "file": "/var/www/html/3rdparty/sabre/dav/lib/DAV/CorePlugin.php",
        "type": "->",
        "function": "updateProperties",
        "class": "Sabre\\DAV\\Server",
        "line": 373
      },
      {
        "line": 89,
        "type": "->",
        "function": "httpPropPatch",
        "file": "/var/www/html/3rdparty/sabre/event/lib/WildcardEmitterTrait.php",
        "class": "Sabre\\DAV\\CorePlugin",
        "args": [
          {
            "__class__": "Sabre\\HTTP\\Request"
          },
          {
            "__class__": "Sabre\\HTTP\\Response"
          }
        ]
      },
      {
        "function": "emit",
        "type": "->",
        "line": 472,
        "args": [
          "method:PROPPATCH",
          [
            {
              "__class__": "Sabre\\HTTP\\Request"
            },
            {
              "__class__": "Sabre\\HTTP\\Response"
            }
          ]
        ],
        "class": "Sabre\\DAV\\Server",
        "file": "/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php"
      },
      {
        "line": 212,
        "class": "Sabre\\DAV\\Server",
        "function": "invokeMethod",
        "type": "->",
        "file": "/var/www/html/apps/dav/lib/Connector/Sabre/Server.php",
        "args": [
          {
            "__class__": "Sabre\\HTTP\\Request"
          },
          {
            "__class__": "Sabre\\HTTP\\Response"
          }
        ]
      },
      {
        "line": 432,
        "class": "OCA\\DAV\\Connector\\Sabre\\Server",
        "type": "->",
        "file": "/var/www/html/apps/dav/lib/Server.php",
        "function": "start",
        "args": []
      },
      {
        "type": "->",
        "line": 25,
        "class": "OCA\\DAV\\Server",
        "args": [],
        "file": "/var/www/html/apps/dav/appinfo/v2/remote.php",
        "function": "exec"
      },
      {
        "args": [
          "/var/www/html/apps/dav/appinfo/v2/remote.php"
        ],
        "function": "require_once",
        "file": "/var/www/html/remote.php",
        "line": 151
      }
    ],
    "app": "webdav",
    "url": "/remote.php/dav/systemtags/7/files",
    "reqId": "Y1xNZVPwR4K92htBvxyH",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.6.2 Safari/605.1.15",
    "message": "You don’t have permissions to update tags",
    "user": "jum"
  },
  "resource": {
    "type": "gce_instance",
    "labels": {
      "instance_id": "redacted",
      "zone": "redacted",
      "project_id": "redacted"
    }
  },
  "timestamp": "2026-09-13T14:25:36.249200958Z",
  "logName": "projects/redacted/logs/ngcplogs-docker-driver",
  "trace": "projects/redacted/traces/f42425cef79adf082d289cc6dfab7534",
  "receiveTimestamp": "2026-09-13T14:25:37.251763004Z",
  "spanId": "563ae5006e5cb678"
}

[PeopleInside]

@jum thank you very much for your message. On those day I through about restoring my backup... because without tag I loose a important function for me.. but if is a bug as I suppose I need just hope in a fix.

With tags this is the seconds issue that I detect in a few days.
I hope this will be resolved very soon or tag did not work, I cannot schedule file deletion anymore, etc.

Also if a fix will be available I hope to read here how I can apply asap.

Let's hoping in developers.