Changeble External Shares without loosing ALL Relatet Shares

[thechonta]

Hello,

we are using a lot of SMB External shares in out Nextcloud.
The Problem is, if you change the Servername or anything of the Path of the share, all Nextcloudshares that was createt for folders of that smb share, will not work!
That is a bit of a Problem, having hundreds of Nextcloud shares and to have to migrate the SMB Server (or any other external share source)

It would be awesome, if you could alter the process of renaming an existing external share to an real Updating process and not yust creating an new entry.

It is possible.
At the moment for making it work, you have to change the external store to the path you want in the nextcloud WebInterface.
A new entry will be than createt in the oc_storrage.
And all Shares stop working.

If you now log in to the database and delete the new createt line and than alter the path of the old one to the new one, the share will work again with the new serverpath of the external share.

Bit it can be that it is not the only part you need to change.
I gues the oc_filecache could also be needed to get some update

It would really help a lot to alter the Server for external shares.

Kind Regards

Gunther

[thechonta]

Addendum

If the path is updated directly on the database level
by modifying public.oc_external_config to the new path and saving it,
and then updating the corresponding row in public.oc_storages with the new path as well,
everything works immediately.

When the change is made via the web interface, modifying the configuration automatically creates a new entry and treats the change as if the storage was newly created, which is incorrect (in my opinion).

[thechonta]

Why every User needs his own Storage ID for external shares?
That makes no sense, there is only one server and if a user has access is a question of acl and yes or no :-(

all the n to n relations in all the tables is way to much overhead

[come-nc]

Hello,

The issue is that it’s not possible for the Nextcloud server to know the internals of the SMB server. So it cannot know if the server will the same files for all users, and it cannot know if the server will return the same files when you change the root path or the servername.
This is why username and path are part of the storage id and if you change them we consider this a new storage.

Maybe this can be improved but it’s not trivial how.

[thechonta]

Hello,

the argument with the internal of the SMB is not 100% valid.
Of course it can only work if the file structure on the fileserver does not change.
But it should irrelevant if i change an existing external strage (fileservrname, share, subfolderpath) as long the files at the end is the same.
If it breakes becaus the folder at the windowsserver are gone is ok but everything breakes only i have to change the fileservername is pure horror.
and because OC_storage is never emptyed oc_filecashe will not be updated it will create for every file and every user a new file entry with the new mountpoint id as source. 100 user and 1TB of data extra in the oc_filecache.

but thanks for looking into it, would be very helpful a lot and preventing a lot of ressources geting eaten.
btw. is the problem fixed, that if an user writes his login name different (user | User | USER) everytime a new storage > Mount gets createt that lead to a nee oc_filecache and also let oc_share breake?

[thechonta]

ok seems the Problem where a store/filecache/mountpoint entry gets always created depending on how the user name was written still exist, at lease weht the user is comming from an AD/LDAP user backend and the credentials for access the external store are saved in the database.

[come-nc]

Having the id changing is anyway a bad idea as it leaves data behind. So I guess we should make the id stable and only trigger a new scan or something when login data changes. But we do need the information somehow of whether the data is the same for all users or different for each one. Could be a checkbox in the storage configuration.
But it’s not an easy fix.

[thechonta]

Not an easy fix is true, because Nextcloud has a lot of mechanism that are broken by design since owncloudtime. But it would be worth it to fix that and have an strong fundament for the future.
in case of the external storage.
at the moment everything breaks anyway if something changes.
changing anything should not be handled as a new creation.
the system should know wich field is for what and is used somewhere else and than simply update.
or everything just get linked, so there is only one field that is the source of truth.

the database is a monster and it take days even figuring out how to repair shares that got broken, becaus an ldap user logged in differently and was a new mount got createt für that writing.....
but it is possible.