Bogus shared:: storage entry in oc_storages

[PVince81]

Steps

1. Setup OC 9.0.1
2. Enable encryption
3. Create two users "user1" and "user2"
4. Login as "user1"
5. Create a folder "test"
6. Share "test" with "user2"
7. Login as "user2"
8. Create a subfolder "test/sub"
9. Upload a non-empty file into "test/sub" in the web UI
10. Navigate to folder "test"
11. Check the size of the folder "sub"
    (from Folder size not propagated when uploading as share recipient with encryption enabled #24105 as that's where I observed this while looking at the DB)

Expected result

No bogus storage in oc_storages

Actual result

Bogus "shared::" storage for the local share:

MariaDB [owncloud]> select * from oc_storages;
+---------------------------------------+------------+-----------+--------------+
| id                                    | numeric_id | available | last_checked |
+---------------------------------------+------------+-----------+--------------+
| home::admin                           |          1 |         1 |         NULL |
| local::/srv/www/htdocs/owncloud/data/ |          2 |         1 |         NULL |
| home::user1                           |          3 |         1 |         NULL |
| home::user2                           |          4 |         1 |         NULL |
| shared::/test                         |          5 |         1 |         NULL |
+---------------------------------------+------------+-----------+--------------+

Versions

ownCloud 9.0.1

@icewind1991 @rullzer is this something new in 9.0.1 or is this a bug ?

[PVince81]

There are no oc_filecache entries for that storage though, and no oc_mounts entry points to that.

[rullzer]

No idea why this is happening... @schiesbn maybe?

[PVince81]

@icewind1991 can we prevent this somehow ?

[PVince81]

Hmmm, I can't reproduce this in 9.1.0RC2 with or without encryption. Maybe it's fixed.

[PVince81]

But still happens in 9.0.4RC1.

[PVince81]

TODO:

• find out which commit fixes this and backport it
• provide repair step that deletes the bogus entries:
  • find all storage entries that have no filecache entries
  • find the storage type to check if it's a "shared::" storage, requires resolving through "oc_mounts" and setup FS for each found user to get to the correct storage type (in case of md5 storages)

[PVince81]

• also fix oc_mounts to point to the correct storage id, which is the one of the owner to delete the bogus entries, they will get recreated: [stable9.1] Repair oc_mounts' shared:: storages that must not be #25804

[PVince81]

Increasing to high. After seeing that oc_mounts also point to the wrong storages I'm having a bad feeling about possible side effects.

[PVince81]

Hmmm... bisecting shows that the commits that fix it are the ones that moved the shared storage to be a jail wrapper:
6123bad
afa37d3

from #23919

Ok then, let's see if there is a way to fix in on OC 9.0 only

[PVince81]

I suspect that it works properly on 9.1 because when using the Jail wrapper, asking for the shared storage id would pass the call to the wrapped storage while in 9.0 it would just call SharedStorage::getId

[PVince81]

Idea for the repair step: check whether oc_mounts.rootId resolved in oc_filecache.storage. If the storage doesn't match, fix it.

• TODO: make sure it also works properly after running RepairUnmergedShares where oc_mounts might have duplicates, these must disappear after the upgrade

[PVince81]

Repair step for oc_mounts: #25804

Now I realize that we'd also better delete the bogus "shared::" entries which is easy as long as we're not dealing with md5 ids...

[PVince81]

I need to retry this. Some backports done to OC 9 related to shared storages might fix this.

[PVince81]

Just retried with 9.0.8 and the bogus storages cannot be recreated.

I'm closing this ticket but let's keep the PR for cleaning up the old mess...

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.