Open huntervcx opened 2 days ago
Tried to truncate oc_filecache multiple times
Congratulations, you just broke your server. You should not purge that table. The fileids are reused in other places, e.g. in shares and that is mostlikely what is causing your issue
Issue was before the truncate on a new server initialized with the same smb shares; and same issue on other server on v29.0.0.19 (with auto truncate enabled, admit for this one) Tried the truncate as it was a same behavior as #45238 (showing wrong folder listing, truncate was the only way to refresh)
Problem remains the same : NC doesn't seems to load the files from backend share but only from his filecache table. And doesn't compare file_hash, as it opens files from other shares, that the user never had access to
Why in hell did you think it was a good idea to truncate an essential table for Nextcloud? This could NEVER be a solution for anything 😭
Only a backup restore can save you, otherwise you're good to restart your server from scratch.
Sorry to say, but this is not a bug, and no-one can help you here. 🥴
Issue was before the truncate on a new server initialized with the same smb shares; and same issue on other server on v29.0.0.19 (with auto truncate enabled, admit for this one) Tried the truncate as it was a same behavior as #45238 (showing wrong folder listing, truncate was the only way to refresh)
Problem remains the same : NC doesn't seems to load the files from backend share but only from his filecache table. And doesn't compare file_hash, as it opens files from other shares, that the user never had access to
As said just before, on a new server with same setup, same behavior after a while (>20days) and random folders/files, and pretty big oc_filecache table with fileid corresponding on other tables. truncate was a test on a secondary server, with same config, that temporarly fixed other issues of listing folders on external storage
the issue is here without any modification to the db. That's why I reported it initally, as it's random and sometimes revert to the normal files after a lot of time (>6hours while being under massive load from users) Issue also here with or without redis for cache and filelock, with and without preview enabled, some stock apps enabled and disabled
In that case continue your debug at https://github.com/nextcloud/server/issues/45238 because here there is nothing we can do about it.
AGAIN, oc_filecache
is not a "cache" in any means (even if the name of the table is not perfect, it should be more like oc_filetable
).
⚠️ This issue respects the following points: ⚠️
Bug description
Users can open files that are from other shares, even if they don't have an access to with their account Totally random on the files or folders
Tried to truncate oc_filecache multiple times (related to #45238 ), nothing changed
First asumptions would be an error using the fileID used by nextcloud
Steps to reproduce
Pretty random, can be reproductible by truncate oc_filecache multiple times. Files will show wrong thumbnails, or even open other files
Expected behavior
See and open the good file, not access files from others shares that the user doesn't have any access to
Installation method
Community Manual installation with Archive
Nextcloud Server version
27
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
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. 22.1 to 22.2)
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
This can be considered as a security issue, but hackerone is locked to submit
Issue present on v29.0.0.19 and v29.0.3.4