Changed file IDs in Groupfolders

[gzoritchak]

We experienced the same issue mentioned here:

https://help.nextcloud.com/t/changed-file-ids-in-groupfolders/91916

It's very annoying since we used a root spreadsheet to referenced a lot of internal documents. All links are now broken.

[fschrempf]

@juliushaertl @icewind1991 Are the file ids meant to stay unchanged? If yes, this is a bug. If no there should be something in the docs that informs users about this. Personally I think it is a bug? What's your point of view?

[juliusknorr]

Yes, file ids should remain unchanged and I haven't encountered such a behavior until now. Please fill out the issue template and it would be especially interesting if there is any groupfolder related errors in the logs. Might also be worth to check if there was any suspicious action like a delete or move during the time this occured in the access logs of the webserver.

[solracsf]

Hi @juliushaertl there was nothing in the logs either about group folders or anything else. The problem faced by @gzoritchak has arrived at night, with little or no activity at all.

After investigation, at the SQL dump from 3h26am (nightly backup) & production at 13h43 the same day, we could obseve an ID 2281 and an ID 6208 for the same file, exposing this ID increment, respectivelly (this is an example, all files were affected).

There was nothing unusual in the webserver, database, php or nextcloud logs. Only things related to #1381 and #1472 essentially.

[SimJoSt]

@juliushaertl when we encountered this, there was a bulk file ownership change on the server. The file ownerships were adjusted to match the ones used by the Nextcloud Docker image. Some files were previously owned by the root user and group.
The change was made with chown.

[konfiot]

Also experienced the same issue, we did a files:scan for manually imported files, and some file ids have changed in other group folders, maybe this has something to do with the ids changing

[freshdomi]

we have the same problem after moving the data directory....
I have checked that in the table oc_filecache, entries are duplicated. Example below..

Have anyone a solution for this problem?
Our current idea is that we replace the fileids of the new database with the old one... but if that will work...
would be great if someone has another idea that does not attack the DB...

example: (same path but different fileid)

MariaDB [nextcloud]> SELECT * FROM oc_filecache WHERE fileid=3485643;
+---------+---------+------------------------------------------------+----------------------------------+---------+-----------+----------+----------+----------+------------+---------------+-----------+-----          -------------+---------------+-------------+----------+
| fileid  | storage | path                                           | path_hash                        | parent  | name      | mimetype | mimepart | size     | mtime      | storage_mtime | encrypted | unen          crypted_size | etag          | permissions | checksum |
+---------+---------+------------------------------------------------+----------------------------------+---------+-----------+----------+----------+----------+------------+---------------+-----------+-----          -------------+---------------+-------------+----------+
| 3485643 |     280 | __groupfolders/83/2021-09-10_ISAB-02/Upload AM | e9779aced0ca83c359098cc637dfebf1 | 3485639 | Upload AM |        2 |        1 | 61154122 | 1629368109 |    1629367052 |         0 |                          0 | 611e2f2d32386 |          31 |          |
+---------+---------+------------------------------------------------+----------------------------------+---------+-----------+----------+----------+----------+------------+---------------+-----------+-----          -------------+---------------+-------------+----------+
1 row in set (0.00 sec)

MariaDB [nextcloud]> SELECT * FROM oc_filecache WHERE fileid=1689517;
+---------+---------+------------------------------------------------+----------------------------------+---------+-----------+----------+----------+----------+------------+---------------+-----------+-----          -------------+---------------+-------------+----------+
| fileid  | storage | path                                           | path_hash                        | parent  | name      | mimetype | mimepart | size     | mtime      | storage_mtime | encrypted | unen          crypted_size | etag          | permissions | checksum |
+---------+---------+------------------------------------------------+----------------------------------+---------+-----------+----------+----------+----------+------------+---------------+-----------+-----          -------------+---------------+-------------+----------+
| 1689517 |       1 | __groupfolders/83/2021-09-10_ISAB-02/Upload AM | e9779aced0ca83c359098cc637dfebf1 | 1689457 | Upload AM |        2 |        1 | 48815043 | 1629124416 |    1629124416 |         0 |                          0 | 611a7740865db |          31 |          |
+---------+---------+------------------------------------------------+----------------------------------+---------+-----------+----------+----------+----------+------------+---------------+-----------+-----          -------------+---------------+-------------+----------+
1 row in set (0.00 sec)

[juliusknorr]

When moving the data directory to a different path this is expected as the existing filecache entries are not longer valid for the new location. For a possible workaround for that see https://help.nextcloud.com/t/howto-change-move-data-directory-after-installation/17170 however this is not a supported approach.

Note that execution of the scan command could cause creation of new filecache entries if Nextcloud is not able to map the existing entries to the path.

[freshdomi]

after this instruction I have actually also proceeded... I have just not updated the oc_storage table... should be no longer necessary from version 13.1 I thought...
but now our problem is that I have moved the directory 3 days ago and the operation continued normally... today we have seen that the shares are no longer there...
Is this now a problem if I adjust the oc_storage afterwards?

[individual-it]

Has anyone ever found the reason for this issue (besides moving the data folder)?