Maintenance tool to deal with orphaned storages

[blizzz]

Since 9.0 shares in orphaned storages throw Exceptions (cf. #22976 (comment)). ownCloud is still operable and no data is broken or lost or anything, but these Exceptions do occur and or logged.

Two reasons are known for orphaned storages:

• an external storage path was changed in the configuration despite being already in use
• a user was deleted, but no cleanup was done (ownCloud behaviour a long time ago)

Two possible solutions are suggested:

1. Go through the existing storages and figure out which ones are orphaned. home:: storages by checking whether the user exists, local::storages by checking whether the mountpoint exists. If an orphaned storaged was found, all possible remainings in the database need to be purged (e.g. filecache, shares, preferences…). Problem: not all storages can be resolved to a user or path.
2. When the mentioned Exception occurs, flag the related storage. A background job might do some verifications (e.g. validate that no existing user or mount can be found for this storage). An occ tool that cleans up all|specified storages and all connected relations (filecache, shares, etc.)

Opinions? Other approaches? @PVince81 @DeepDiver1975 @icewind1991 @nickvergessen @MorrisJobke

[PVince81]

As discussed before, we can't go through all "home::" storages because some are md5-ied, so we can't resolve the user id. We need to start with all user ids to be able to find matching storages.
"oc_mounts" could be used potentally, but the trouble is that it's only initialized when setupFS is called.

[danimo]

@PVince81 If they are stored as md5, how can they ever be looked up successfully again?

[PVince81]

Originally, back in older OCs when this was introduced, it was only used when the user id was already known. If you log in as "user1" then it would concatenate with "home::user1" and do the md5 only if it's longer than 64 chars. Can happen with long user ids like LDAP ids.

Same for shares, at that time the user ids are already known. So basically you could only resolve storages in a single direction.

Yeah, I hate this too...

[blizzz]

What @danimo has in mind is that you can take the known user-ids and brute-force-hash them until it matches with a storage.

[MorrisJobke]

@PVince81 If they are stored as md5, how can they ever be looked up successfully again?

https://github.com/owncloud/core/wiki/Storage-IDs

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[PVince81]

leaving closed in favor of #18922

[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.