Error : Current version of a groupfolders file was listed for deletion

[major-mayer]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Steps to reproduce

1. Update groupfolders to the latest version
2. Have some files "listed for deletion"
3. Run cron.php

Expected behaviour

Before the update, no logs popped up on level 3

Actual behaviour

The logs are flooded with "Current version of a groupfolders file was listed for deletion. Skipping." on level 3.
I think this level is too high for such a minor note and should be reduced to reduce the log spam again.

Server configuration

Operating system: docker image

Web server: php fpm

Database:

PHP version:

Nextcloud version: 31.0.12

Team folders version: 19.1.12

Updated from an older Nextcloud/ownCloud or fresh install: updated

Where did you install Nextcloud from: Docker php fpm image

Are you using external storage, if yes which one: no

Are you using encryption: no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/Saml/...

Client configuration

Browser:

Operating system:

Logs

[nextcloud][groupfolders][3] {"reqId":"hwn5f2Dbgt4mo1mgoZjH","level":3,"time":"2025-12-14T09:30:03+00:00","remoteAddr":"","user":"--","app":"groupfolders","method":"","url":"--","message":"Current version of a groupfolders file was listed for deletion. Skipping.","userAgent":"--","version":"31.0.12.3","data":{"app":"groupfolders","folderid":"1","timestamp":"1694459757","mtime":"1694459757","sourcefilename":"Beilf\u00fchrerschein - Vorderseite.doc"}}
[nextcloud][groupfolders][3] {"reqId":"hwn5f2Dbgt4mo1mgoZjH","level":3,"time":"2025-12-14T09:30:03+00:00","remoteAddr":"","user":"--","app":"groupfolders","method":"","url":"--","message":"Current version of a groupfolders file was listed for deletion. Skipping.","userAgent":"--","version":"31.0.12.3","data":{"app":"groupfolders","folderid":"1","timestamp":"1590765677","mtime":"1590765677","sourcefilename":"Android.m4v"}}
[nextcloud][groupfolders][3]

Web server error log

Web server error log

Insert your webserver log here

Nextcloud log (data/nextcloud.log)

Nextcloud log

Insert your Nextcloud log here

Browser log

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log
c) ...

[provokateurin]

This was very deliberate in order to prevent #4146. CC @come-nc

[come-nc]

Hello.

The log is high on purpose because this should not happen. We are trying to fix issue #4146 . As I could not find the source issue, I released a version logging instead of deleting to avoid data loss.

Do you have this for a lot of files?

Can you try to inspect for those files if you have versions in oc_group_folders_versions with an mtime newer than the one in the log line? (or in oc_filecache, should be the same as the log line)

[bturmann]

Hallo,
I am affected with this issue as well and start investigating. Let me share some details:

Current Nextcloud env:
Version: 32.0.3
apps installed:

• calendar
• contacts
• groupfolders
• impersonate
• spreed
• user_saml

Currently, the Admin Overview says:

"Fehler im Protokoll:
102.367 Fehler in den Protokollen seit 8. Dezember 2025, 12:18:42"
(obviously, the number is growing after each cron execution)

After downloading the protocol and search, there are 102.358 entries with the groupfolders log message.

According to the log, the first message appeared on Fri, 2025-12-12, 14:00 UTC:

{"reqId":"Dao0CLR1svPEnEcSzvf0","level":3,"time":"2025-12-12T14:00:12+00:00","remoteAddr":"","user":"--","app":"groupfolders","method":"","url":"/cron.php","message":"Current version of a groupfolders file was listed for deletion. Skipping.","userAgent":"--","version":"31.0.11.2","data":{"app":"groupfolders","folderid":"2","timestamp":"1690198663","mtime":"1690198663","sourcefilename":"14_What Kind of Man Would I Be.flac"}}

At that time, Nextcloud version was still 31.0.11, but all apps were upgraded, including groupfolders from 19.1.10 to 19.1.12. Shortly after, I upgraded to 31.0.12:

{"reqId":"72rvWcp0Aglapie48l0I","level":0,"time":"2025-12-12T14:04:17+00:00","remoteAddr":"","user":"--","app":"core","method":"","url":"/occ","message":"starting upgrade from 31.0.11.2 to 31.0.12.3","userAgent":"--","version":"31.0.11.2","data":{"app":"core"}}

And finally, upgrading to 32.0.3 (including groupfolders to 20.1.6):

{"reqId":"bVuiPpR3dLU6JkjIjvLR","level":0,"time":"2025-12-12T14:40:32+00:00","remoteAddr":"","user":"--","app":"core","method":"","url":"/occ","message":"starting upgrade from 31.0.12.3 to 32.0.3.2","userAgent":"--","version":"31.0.12.3","data":{"app":"core"}}

There are 2 groupfolders in my setup and there are entries for both, examples of today:

{"reqId":"wgzz4Xwce108Dmlf5M11","level":3,"time":"2025-12-15T11:30:04+00:00","remoteAddr":"","user":"--","app":"groupfolders","method":"","url":"/cron.php","message":"Current version of a groupfolders file was listed for deletion. Skipping.","userAgent":"--","version":"32.0.3.2","data":{"app":"groupfolders","folderid":"1","timestamp":"1701281838","mtime":"1701281838","sourcefilename":"idm.pdf"}}

{"reqId":"aflnI8fKqqOUxKoqVJYw","level":3,"time":"2025-12-15T10:25:17+00:00","remoteAddr":"","user":"--","app":"groupfolders","method":"","url":"/cron.php","message":"Current version of a groupfolders file was listed for deletion. Skipping.","userAgent":"--","version":"32.0.3.2","data":{"app":"groupfolders","folderid":"2","timestamp":"1690198663","mtime":"1690198663","sourcefilename":"14_What Kind of Man Would I Be.flac"}}

Could you tell me what exactly I should check for?

[major-mayer]

Hello.

The log is high on purpose because this should not happen. We are trying to fix issue #4146 . As I could not find the source issue, I released a version logging instead of deleting to avoid data loss.

Do you have this for a lot of files?

Can you try to inspect for those files if you have versions in oc_group_folders_versions with an mtime newer than the one in the log line? (or in oc_filecache, should be the same as the log line)

Hi, good to know that. Then I guess the solution is not to silence these logs, but to fix the underlying issue.
I get these logs for quite a lot files, around 50 probably.
When I'm back at home, I can have a look into those tables.
Is there anything else that I can do to stop the logs appearing?

[major-mayer]

@come-nc I checked two exemplarily files that are mentioned in the logs and indeed, there are versions in the oc_group_folders_version table with an mtime newer than the one logged in the mail (or in the oc_filecache table):

File 1:
log mtime: 1594135715
oc_filecache mtime: 1594135715
oc_group_folders_versions:

id	file_id	timestamp	size	mimetype	metadata
593	1469702	1593188194	16151	19	[]
592	1469702	1594135715	21705	19	[]
594	1469702	1594135839	21690	19	[]

File 2
log mtime: 1606485048
oc_filecache mtime: 1606485048
oc_group_folders_versions:

id	file_id	timestamp	size	mimetype	metadata
625	1573086	1606485048	37618	35	[]
626	1573086	1606485054	37603	35	[]

All assuming that timestamp refers to the mtime attribute, and fileid and file_id mean the same.
It would be helpful to include the file id in the logs, so that one doesn't have to manually join the two tables.

Now that I know that something's wrong, is it somehow possible to disable this logging until we found a solution?
It's really spamming my mail inbox...

[oleua]

I've got the same issue after the last update:

{"reqId":"llXP2mIWeBOZ8HlkS4Nv","level":3,"time":"2025-12-16T21:46:11+02:00","remoteAddr":"","user":"--","app":"groupfolders","method":"","url":"--","message":"Current version of a groupfolders file was listed for deletion. Skipping.","userAgent":"--","version":"30.0.17.2","data":{"app":"groupfolders","folderid":"15","timestamp":"1668835474","mtime":"1668835474","sourcefilename":"file.docx"},"id":"6941bba015069"}

Should I downgrade it?

[come-nc]

@major-mayer Do you know how these files ended up in this situation?
Did you restore an older version?
Were they uploaded via web, client, or modified with collabora or something else?

File 2 is quite puzzling, there are only 6 seconds between the versions and somehow the current one is not the most recent. We see on the version id that the most recent was created after, why is not current 🤔

@artonge Do you have any idea how this situation can happen? I think a webdav upload can specify the mtime in the header, so in that case that would create a version with an older mtime, but it would still have a higher id.

We can easily silence the log and correctly ignore current version in version expiration, but I’m afraid there is another bug hiding in there.

[major-mayer]

@major-mayer Do you know how these files ended up in this situation?
Did you restore an older version?
Were they uploaded via web, client, or modified with collabora or something else?

File 2 is quite puzzling, there are only 6 seconds between the versions and somehow the current one is not the most recent. We see on the version id that the most recent was created after, why is not current 🤔

I haven't edited any of the listed files myself, so I cannot tell for sure.
Most of the files are office files, so theoretically it could be the case that someone restored an older version using Nextcloud or Onlyoffice (we are using that instead of Collabora).
But some of them I am 100% sure have not been changed in years, because nobody in our team cares about them and, maybe more important, they are video files with no easy editing method.

Here you can see one example:

This video was edited the last time in 2020.

Edit: Here are the corresponding versions for this file:

id	file_id	timestamp	size	mimetype	metadata
590	1466375	1590842870	9465703	12	[]
591	1466375	1590842872	48	12	[]

[nextcloud][groupfolders][3] {"reqId":"Z6b3jyjjC3zC1kNN3E7U","level":3,"time":"2025-12-18T09:50:03+00:00","remoteAddr":"","user":"--","app":"groupfolders","method":"","url":"--","message":"Current version of a groupfolders file was listed for deletion. Skipping.","userAgent":"--","version":"31.0.12.3","data":{"app":"groupfolders","folderid":"1","timestamp":"1590842870","mtime":"1590842870","sourcefilename":"iOS.m4v"}}

But I have no idea why there is a 48 byte version of this file that is apparently newer than the currently used one...
Maybe there was an error while uploading back then...

Am I correct that newer versions of the group folders app (in combination with Nextcloud 32) deleted the old but actually current version (1590842870) of the file?
Why are versions being deleted at all?

[come-nc]

Am I correct that newer versions of the group folders app (in combination with Nextcloud 32) deleted the old but actually current version (1590842870) of the file? Why are versions being deleted at all?

Versions in groupfolders are kept following this schedule:

	public const MAX_VERSIONS_PER_INTERVAL = [
		//first 10sec, one version every 2sec
		1 => ['intervalEndsAfter' => 10, 'step' => 2],
		//next minute, one version every 10sec
		2 => ['intervalEndsAfter' => 60, 'step' => 10],
		//next hour, one version every minute
		3 => ['intervalEndsAfter' => 3600, 'step' => 60],
		//next 24h, one version every hour
		4 => ['intervalEndsAfter' => 86400, 'step' => 3600],
		//next 30days, one version per day
		5 => ['intervalEndsAfter' => 2592000, 'step' => 86400],
		//until the end one version per week
		6 => ['intervalEndsAfter' => -1, 'step' => 604800],
	];

Apart from that, versions expire depending on your configuration.

But for the video file you mention, it is older that a month, so the system wants one version per week maximum, so it will delete one of the two. And it keeps the most recent one so it deletes the current one, which deletes the file.

[bturmann]

I did some more investigating:

• There are 2 groupfolders and both are affected.
• Number of files affected in folder one: 41
• Number of files affected in folder two: 3062
• (means, there are more than 3000 entries added during each cron execution)

Following is interesting:

• all logged files have a current version with a timestamp in year 2023
• all logged files have 2 versions within the same months, e.g. "Dez. 2023" (unfortunately, the web ui is not showing a full timestamp or can this be enabled anywhere?)

I checked the versions of about 100 files so far. I did not find any file with a timestamp in 2024 or 2025.

Addtional notes:

• the files are managed only with the Nextcloud Desktop client based on Debian Linux
• web client is not used; there is no office suite installed
• not all, but most files in folder two are FLAC music files created in 2023

Question:
Was there a recent change in how the system is deleting versions?

[winnieXY]

I can confirm the error in my instance:

{"reqId":"VGCi6rKijtXJYkeq2cYj","level":3,"time":"2025-12-18T12:45:02+01:00","remoteAddr":"","user":"--","app":"groupfolders","method":"","url":"--","message":"Current version of a groupfolders file was listed for deletion. Skipping.","userAgent":"--","version":"31.0.11.2","data":{"app":"groupfolders","folderid":"3","timestamp":"1673384264","mtime":"1673384264","sourcefilename":"Abfrage-neue-PV-Anlage.xlsx"},"id":"6943f13063b06"}

The file in question in this case (Abfrage-neue-PV-Anlage.xlsx) has two versions according to the gui:

Hovering over the dates reveals:

• 10.01.2023 21:57:44 (Current version) - size 7Kb
• 10.01.2023 21:58:06 - Size 11 Kb

However if I look into oc_group_folders_versions there is just one listed:

select id,file_id,timestamp,size,mimetype,metadata from oc_group_folders_versions where file_id='1526201';
+-----+---------+------------+-------+----------+----------+
| id  | file_id | timestamp  | size  | mimetype | metadata |
+-----+---------+------------+-------+----------+----------+
| 256 | 1526201 | 1673384264 |  7155 |       14 | []       |
| 257 | 1526201 | 1673384286 | 11166 |       14 | []       |
+-----+---------+------------+-------+----------+----------+
2 rows in set (0.001 sec)

I have within several hours 992 similar messages within my log - this happens to various filetypes:

• xlsx
• xls
• pdf
• svg
• jpeg
• png
• txt
• jpg
• ods
• odt
• afphoto

[come-nc]

@winnieXY The timestamp you show from DB is for 2022, so most likely not the same file.

@bturmann So in your case it could be residues from an older bug. But we have people with recently uploaded files being affected as well, so that’s not all.