In the last couple of months we had a couple of events of yet unknown origin which resulted in new file IDs for all files and directories in group folders. User owned files are not affected. As this happened in many or all of hundreds of group folders and no single user has access to all group folders, I do not think that this was triggered by any user interaction. We also do not see any apparent reason for the event. The resulting problem is that all internal share links are broken. We did notice a slightly increased CPU usage over a couple of hours, while (apparently) the IDs changed or were regenerated?. I now started monitoring some existing files for changing IDs to pinpoint the exact time in the logs if this happens again. Can anyone think of any trigger that could be responsible for the behavior we’re seeing? I currently think that this is probably a bug, but cannot say for sure. Any ideas about debugging this are also appreciated. For me the biggest issue is that this happens only once a few weeks or months, which makes this hard to debug.
We just ran into this issue for the first and have no idea yet what caused it.
The day before we noticed the issue we adjusted our Nextcloud setup. We didn’t update to a newer version, but changed our Docker configuration, adjust MariaDB server settings and integrated Redis better.
None of those changes should trigger a file id change.
I investigated such an issue recently and the most likely cause was a groupfolder scan that ran while the corresponding directory was empty because of a missing mount.
When a groupfolder scan fails to find a file it assumes the file was deleted and removes the entry from the filecache. If the file comes back later (i.e. the mount is back up) the next groupfolder scan will discover it and register it as a new file as it has no way of telling that this file already existed.
In that particular case we restored the previous state from a backup.
