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

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

Apply a label to a folder or a file
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

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:

Permission/capability checks inside apps/systemtags/lib/Controller/ or the DAV plugin handling PROPPATCH on /systemtags/{id}/files.
A change in how workflowengine / files_automatedtagging hooks interact with manual tag assignment.
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.

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"
}

@jum

@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.

🔍 Potential root cause identified: PR #63991 + Database verification

After reviewing the v34.0.4 changelog, I noticed the following change was introduced in this exact release:

Fix: filter system tag object IDs by user visibility (server#63991)

This perfectly matches the symptoms:

The frontend sends a valid WebDAV PROPPATCH request to assign a tag.
The server responds with a silent HTTP 403 Forbidden.
No error is logged in nextcloud.log or the web server error log, indicating the system is treating this as an intentional permission denial rather than a code crash.

🧪 Database verification (ruled out data misconfiguration)

To ensure this wasn't a local data issue, I directly inspected the database:

oc_systemtag: All tags correctly have visibility = 1 and editable = 1.
oc_systemtag_group: This table is completely empty (no group-based restrictions are applied).

Conclusion

Since the database permissions are perfectly valid and unrestricted, the silent 403 Forbidden is definitively caused by a logic error in the new PHP visibility filtering introduced in #63991. It is incorrectly evaluating valid tag assignments as forbidden.

Request to devs: Could you please review the changes in #63991 (specifically in lib/private/SystemTag/ or apps/systemtags/) to see why it rejects valid PROPPATCH requests even when visibility=1 and editable=1?

Is there a temporary workaround (e.g., an occ command or config flag) until a patch (like 34.0.5) is released?

For what its worth, this seems to be a deeper systemtag permissions error. I am unable to even delete or modify system tags now from the WebUI. Not from user who created tags, not from admin user either. My guess is there is some mis-match now in the systemtags DB after the the latest NC update which had significant changes to permissions and file sharing from what I have seen.

Navigation Menu

Repository navigation

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

Bug description

Steps to reproduce

Expected behavior

Nextcloud Server version

Operating system

PHP engine version

Web server

Database engine version

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

Are you using the Nextcloud Server Encryption module?

What user-backends are you using?

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

Additional debugging information

Network-level behavior

Server-side logs are silent

Environment

Relevant enabled apps (versions from 34.0.4)

Impact

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

Suggested areas to investigate

🔍 Potential root cause identified: PR #63991 + Database verification

🧪 Database verification (ruled out data misconfiguration)

Conclusion

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Bug description

Steps to reproduce

Expected behavior

Nextcloud Server version

Operating system

PHP engine version

Web server

Database engine version

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

Are you using the Nextcloud Server Encryption module?

What user-backends are you using?

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

Activity

PeopleInside commented on Sep 12, 2026

Additional debugging information

Network-level behavior

Server-side logs are silent

Environment

Relevant enabled apps (versions from 34.0.4)

Impact

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

Suggested areas to investigate

jum commented on Sep 13, 2026

PeopleInside commented on Sep 13, 2026

PeopleInside commented on Sep 15, 2026

🔍 Potential root cause identified: PR #63991 + Database verification

🧪 Database verification (ruled out data misconfiguration)

Conclusion

reidellawfirm commented on Sep 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions