Decouple home storage entry from user

[PVince81]

Instead of having the home storage id and path be defined by the user id or even hard-coded in oc_accounts table, I suggest to move the following:

1. Replace the oc_accounts table home path with a storage numeric id. Let the storage itself decide where the path is. That column doesn't make sense anyway when dealing with primary object storage or such.

2. Provide a way (API / OCC ?) for admins to change the mapping between users and storages. It could be as simple as changing the numeric id of the storage in oc_accounts table.

This would make it possible to:

1. Rewire users to their correct storage in case of storage duplication issues (which were met due to very old storage bugs)

2. Transfer ownership by reassigning a storage to a new user.

3. In the same line like 2), it would make it possible to transfer a guest user's storage to the real user after migrating said guest user to be a real user (ex: created in LDAP)

4. Like 3 but when a user changed the id, uuid, or whatever, instead of getting a new storage, the admin can remap said user to their old storage so they can keep the data

5. Potentially helping with migrating storage from local storage to object store on a per user basis, given that we extend the oc_storages table to hold the information whether the storage is local or object store instead of just "home::". Maybe add a type column there.

Setting to p2 as this has great potential to address several of our big pain points.

@DeepDiver1975 @pmaier1 @butonic @jvillafanez

[PVince81]

There's a problem with oc_share though: even if the home storage is used by another user, we'd also need to change the value of oc_share.uid_owner to match said user. Not sure what happens with the current code when said value is different. We could also get rid of uid_owner completely and rely on file_source to find the original storage's owner...

[PVince81]

Regarding the actual location of the home folder, this should be either a field in oc_storages, or we should make it a field in oc_external_mount. Basically reuse oc_external_mount and oc_external_mount_config to configure local home storages, and have the path in there.

oc_accounts would then only point to the oc_storages numeric_id.

[PVince81]

I could imagine a new web UI that looks like the external storage one, but for managing all existing known storages, home storages, primary home storages and external storages. (of course with a save button this time).

Then for each storage, can specify a user (autocomplete) for who this is to be used as primary storage.

In the settings/users page the opposite case would be possible: have a field to select the primary storage id from a dropdown / autocomplete.

Only one to one relationships allowed for now.
Well, or we could explore what would happen if multiple users have the same home storage... might be interesting.

[PVince81]

In theory, with the current architecture... if we allowed to specify "/" in the external storages UI, how would an admin configure the current default storages ?

It would be a storage of type "Local" pointing at the folder "/srv/ocdata/data/$user" and applied to all users. So all users would have their home there.

This brings up the question: how to do wildcard mounting of storages, basically assigning several users to the same storage but using a subdirectory for said users. The above shows that.

However note that with the current implementation this would result in several "oc_storages" entries.
So we might need to redefine what we mean with storage when we talk about assigning and decoupling. Maybe what we should mean here is "storage configuration", not actual storage entries in oc_storages. In the end, I think the same result can be achieved: assign a oc_external_config mount point to a specific user. So oc_accounts would have a column "storage_mount" entry that contains the id of said mount.

[PVince81]

From what I see, oc_external_config has a mount id but also contains a mount point:

MariaDB [owncloud]> describe oc_external_mounts;
+-----------------+--------------+------+-----+---------+----------------+
| Field           | Type         | Null | Key | Default | Extra          |
+-----------------+--------------+------+-----+---------+----------------+
| mount_id        | bigint(20)   | NO   | PRI | NULL    | auto_increment |
| mount_point     | varchar(128) | NO   |     | NULL    |                |
| storage_backend | varchar(64)  | NO   |     | NULL    |                |
| auth_backend    | varchar(64)  | NO   |     | NULL    |                |
| priority        | int(11)      | NO   |     | 100     |                |
| type            | int(11)      | NO   |     | NULL    |                |
+-----------------+--------------+------+-----+---------+----------------+
6 rows in set (0.02 sec)

MariaDB [owncloud]> describe oc_external_config;
+-----------+---------------+------+-----+---------+----------------+
| Field     | Type          | Null | Key | Default | Extra          |
+-----------+---------------+------+-----+---------+----------------+
| config_id | bigint(20)    | NO   | PRI | NULL    | auto_increment |
| mount_id  | bigint(20)    | NO   | MUL | NULL    |                |
| key       | varchar(64)   | NO   |     | NULL    |                |
| value     | varchar(4096) | NO   |     | NULL    |                |
+-----------+---------------+------+-----+---------+----------------+
4 rows in set (0.00 sec)

The fact that the mount point is directly here might be problematic and might need decoupling so we have a single mount per user...

Needs further research. My intuition tells me that it might be possible to make this work without too many changes.

[PVince81]

Looks like if we want the flexibility of being able to reassign individual storages (storage config/mount) to users, the admin cannot use a global mount with the "$user" variable.

We'd rather need a mechanism to auto-create the default home mount for every user.

It seems we could use the "applicable" field to assign a home mount to a single user. Or simply use a personal storage. So setting up a using would be about initializing a personal mount mounted to "$userId/files" in ownCloud's VFS by default, of type "Local" and pointing to wherever the user's home directory is by default. Then the admin can make changes, either the home directory path or even swap the storage with another user by changing the "applicable" value. This implies that the admin is able to configure the personal mount points of every user over the UI ! (already possible on the CLI)

[PVince81]

• needs diagrams
• needs mock ups
• needs to work also with primary object store

To be continued...

[mmattel]

Yes, this needs diagrams and mocked up screenshots for fully understanding 😄

[PVince81]

Another possible extension: not only separating user files but also storing metadata (trashbin, versions, thumbnails) on different storages. Technically it is already possible to mount arbitrary storages to these subfolders but there is no place to configure that and it's not automatic. (#8319 requests this)

[mmattel]

For thumbs, I propose a centralized solution. Discussions started in #28939 #25033 and #25770
Moving thumbs just out without centralizing it is imho not really satisfying...