[Bug]: System tag assignment silently fails after tagged file is deleted

[vunky-himawan]

⚠️ This issue respects the following points: ⚠️

• This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug (if unsure, ask the Community Help Forum).
• This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
• I'm using a maintained major version of Nextcloud Server and tested against the latest patch level. (Supported major versions and current patch levels).
• I agree to follow Nextcloud's Code of Conduct.
• I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.

Bug description

When a tag has been assigned to a file or folder, and that file/folder is subsequently deleted, attempting to assign the same system tag to a different file afterwards fails silently (no visible error in the UI). The tag assignment simply does not take effect.

The only workarounds found so far are:

1. Restore the deleted file/folder from the trash, unassign the tag from it, and then the tag can be assigned to the new file normally, or
2. Delete the tag entirely via the admin Tags settings and recreate a new tag with the same name.

This suggests a stale row is left behind in oc_systemtag_object_mapping referencing the deleted file's fileid/tagid pair, which blocks or conflicts with new assignments of the same tag.

Steps to reproduce

1. Create a new tag (e.g. "Test").
2. Assign the tag to a file or folder (File A).
3. Delete File A (send it to trash, or permanently delete it).
4. Try to assign the same tag ("Test") to a different file (File B).
5. The assignment fails — the tag does not get applied to File B.

Expected behavior

Deleting a tagged file should not affect the ability to assign the same tag to other, unrelated files. The tag assignment mapping for the deleted file should either be cleaned up automatically, or at minimum not interfere with tagging other files.

Nextcloud Server version

33

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.5

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?

None

What user-backends are you using?

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

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

No response

[icewind1991]

Can confirm

[icewind1991]

Caused by

• adding/removing a tag is done by setting the new full list of fileids for the tag
• the list of existing fileids for the tag filters out any file not inside the users home (the trashbin is outside)
• the api calculates a list of added/removed tags, but doesn't filter out files outside the users home, so it erroneously thinks the trashed file has the tag removed.
• the check if the user has sufficient permissions for all added/removed fails because it only looks file files inside the users home

Ideally adding/removing a tag wouldn't consist of setting the new full list of files, but instead just pass the files to be added/removed. The current system is also susceptible to race conditions.

Separately, the "set all fileids for a tag" should also be fixed to not fail on trashed files.

[digiandi]

I can confirm this issue on Nextcloud 34.0.4 with MySQL.

In my case the browser shows a failed DAV request:

PROPPATCH /remote.php/dav/systemtags//files

HTTP 403 Forbidden

Response:

<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Sabre\DAV\Exception\Forbidden</s:exception>
<s:message>You don’t have permissions to update tags</s:message>
</d:error>

I inspected oc_systemtag_object_mapping and oc_filecache for the affected tag.

The tag had 10 mappings:

• 9 mappings referred to existing oc_filecache entries below files_trashbin/
• 1 mapping referred to a normal file below files/
• none of the file IDs were orphaned

Example pattern:

systemtagid | objectid | path
------------+----------+-------------------------------
16 | ... | files_trashbin/files/...
16 | ... | files/Freigaben/...

I then removed ONLY the mappings belonging to files_trashbin entries from
oc_systemtag_object_mapping.

No files were deleted or modified.

Immediately afterwards, assigning the same tag to another file worked again.

This also appears to explain the code path in:

apps/dav/lib/SystemTag/SystemTagPlugin.php

handleUpdateProperties() loads all current mappings:

$taggedObjects = $this->tagMapper->getObjectIdsForTags(
[$node->getSystemTag()->getId()],
'files'
);

It then calculates removedObjects by comparing these mappings with the object
IDs sent by the client.

The resulting IDs are passed to:

canUpdateTagForFileIds()

which resolves each file ID through the normal user folder. A file located in
files_trashbin cannot be resolved there, so the permission check returns false
and the complete PROPPATCH fails with:

"You don’t have permissions to update tags"

So this does not appear to be PostgreSQL-specific and is still reproducible
with Nextcloud 34.0.4 + MySQL.