Hello,
We have exactly the same problem. We have been looking for a solution for 32 days, but haven’t found anything. Since I saw this bug report, which matches our problem 100%, I thought I’d write about it.
Is this the first time you’ve seen this error? Yes
When did this problem seem to first start? Since update to 23.0.0 (32 days ago)
Installation method: manually and cli
Are you using CloudfIare, mod_security, or similar? no
We also have absolutely no log entries. We checked:
Nextcloud Activity (no entries for these files)
nextcloud.log (no entries for these files)
apache/access.log (no client connect on this file)
apache/error.log
php8.2-fpm.log
The error usually becomes apparent the next day because the Nextcloud clients start deleting files after work begins. We couldn’t find a trigger. Only a few individual random files are affected. Currently, this mostly occurs in group folders. However, we do not know whether this also affects other files. So far, we have no idea what could trigger the deletion.
If it were a Nextcloud client, then you should actually be able to see that in the access.log. (Apache). You should see DELETE api calls there. I checked that. We don’t have any DELETE entries in the access.log for the period when our files disappeared. (By the way, this usually happens at night for us. At that time, there’s hardly ever anyone logged in anyway.)
I’m not sure we can exclude this.
It could be a trigger caused by the v4 client that the server thinks this file shouldnt be here and get vanished or something.
this is VERY problematic anyway, and for sure this happens more on other NC installations, but not yet reported or users have no clue where there files are.
I actively monitor (with inotifywait) those files that vanished, because they tend to disappear again. I restored a same file already 3 times, where the user told me it vanished again.
Tonight I put those v4 clients back to v3.x.
I come back here with any useful info I have.
It would also be interesting to know:
1/ if this happens on NC servers that got upgraded to 32.0.1
2/ if this never happened yet on NC servers that are a clean first 32.0.1 installation
It would be helpful if you included your actual config (occ config:list system output) and installed apps (occ app:list) as was requested in the support template. You didn’t really provide much to go on so at least provide the basics.
For example, there are tremendous differences when it comes to troubleshooting paths depending whether things like Teamfolders/groupfolders, shared files, etc. are involved.
Any other context too like your underlying storage/filesystem setup/details would be potentially insightful too.
I’m experiencing the exact same problem since the update to version 32.0.0 (updated 2025-10-05), which is still present in 32.0.1.
My observations align with EBB-IT’s report, as the missing files all occurred in group folders. I haven’t been able to find any trace of deletion or activity in the system logs.
Furthermore, nothing is recorded in the database’s oc_activity table when I search using the object_id of one of the affected files.
Nextcloud stores directly on the file system. The folder modification dates often show nighttime hours. I’ve noticed that this particularly affects XLS files.
Nextcloud stores directly on the file system. The folder modification dates often show nighttime hours. I’ve noticed that this particularly affects XLS files.
That applies to me too. At night and mostly spreadsheet files.
APPS list, which is exactly the same like before the upgrade:
Enabled:
activity: 5.0.0-dev.0
admin_audit: 1.22.0 (installed extra after update)
app_api: 32.0.0
bruteforcesettings: 5.0.0-dev.0
circles: 32.0.0
cloud_federation_api: 1.16.0
comments: 1.22.0
contactsinteraction: 1.13.1
dashboard: 7.12.0
dav: 1.34.2
federatedfilesharing: 1.22.0
federation: 1.22.0
files: 2.4.0
files_downloadlimit: 5.0.0-dev.0
files_pdfviewer: 5.0.0-dev.0
files_reminders: 1.5.0
files_sharing: 1.24.0
files_trashbin: 1.22.0
files_versions: 1.25.0
firstrunwizard: 5.0.0-dev.0
groupfolders: 20.1.3
logreader: 5.0.0-dev.0
lookup_server_connector: 1.20.0
notifications: 5.0.0-dev.0
oauth2: 1.20.0
onlyoffice: 9.11.0
password_policy: 4.0.0-dev.0
photos: 5.0.0-dev.1
privacy: 4.0.0-dev.0
profile: 1.1.0
provisioning_api: 1.22.0
recommendations: 5.0.0-dev.0
related_resources: 3.0.0-dev.0
richdocuments: 9.0.1
richdocumentscode: 25.4.504
serverinfo: 4.0.0-dev.0
settings: 1.15.1
sharebymail: 1.22.0
sociallogin: 6.3.0
support: 4.0.0-dev.0
survey_client: 4.0.0-dev.0
systemtags: 1.22.0
text: 6.0.1
theming: 2.7.0
twofactor_backupcodes: 1.21.0
updatenotification: 1.22.0
user_saml: 7.1.0
viewer: 5.0.0-dev.0
webhook_listeners: 1.3.0
workflowengine: 2.14.0
We
Yes, this is for me too:
mostly only Excel files
also in TeamFolders (aka Groupfolders)
collabora is intalled (but they dont use it)
Php: php8.4-fpm.service
I activated a monitor on file deletion on Linux server level with ausearch. We have again a file dissapeared, in the log: nothing!
So, we can say that the file didnt dissapeared, but Moved, my analysis below so far I understand this issue:
We do however find the file in a trash folder in another GroupFolder:
/var/www/html/data/__groupfolders/26/file.xls < where the file dissapears
/var/www/html/data/__groupfolders/trash/17/VOERTUIGEN.d1744272692/file.xls < where it is still found
I do start start to think the problem arises when the file exists in another folder, like trash.
This problem started upon upgrading the server and/or with combination of the client syn app version 4.x
So I think this problem arise when a same filename exists somewhere else in /data/
Can you search also for the dissapeared filename in the whole nextcloud /data/?
Update: we have also vanished files that are not elsewhere in a Trash for example
I can confirm that, for me, the malfunction occurred after a server update, not a client update.
That’s helpful info.
FYI: The Teamfolders app would have also been updated automatically when you bumped to Server v32.
I’m definitely getting off this nextcloud-boat. This is undoable on corporate level.
For what it’s worth, there are always at least two major release branches supported by the project (i.e. actively receiving bug fixes). And enterprise environments often stick to latest-1 (i.e., v31 at the moment).
Even without a paid arrangement with Nextcloud GmbH, each major release branch is supported (receives bug fixes) for one year. There are typically ~3 major releases a year, each receiving support until they reach end-of-life.
Deploying brand-new major releases early in the release cycle is always more likely to invite issues with apps, compatibility problems, or new bugs.
Although if I would find any other smoking gun later on (on remaining testservers), I let it know here so others can resolve their similar problems.
Thanks for contributing back to the community! Sorry about your experience.
I know this doesn’t help anyone, but I’m relieved that the Groupfolders app appears to be the culprint
I ditched it a long time ago because it was often incompatible with new NC versions and it’s not the first time it has caused strange side effects, even when it was listed as compatible. I would recommend avoiding this app, especially if you want to update early and enjoy new features.
Having said that, I also understand that Groupfolders is a necessity in many businesses. Nextcloud really needs to treat the app as a first-class citizen. In my opinion, there should be no incompatibilities, especially none that could lead to data loss.
Same problem appeared for me as well after upgrading to 32.0.1 with groupfolders enabled, PHP8.4 on Debian 13.
Files disappearing randomly at nighttime, in my case up to 30GB… (Didnt check for every file, but thats the dip my monitoring of the data partition recorded)
Thankfully i did a VM snapshot before upgrading, so i immediately rolled back to NC 31 once i saw this mess.
1/the files that are disappearing are only Excel files with the old extension XLS
2/ we installed on our nextcloud server “ssconvert“ to batch convert all the xls-files to extension xlsx. You CANNOT just change the extension, you need to convert it this way.
be aware of the specs!! it’s converting very well regular excel, but not complex spreadsheets with VBS scripts and so on.
