Add support for shared file IDs on SMB storage

[ddean4040]

Add a checkbox in external storage config so an admin can mark that external SMB storage is shared among users. If checked, Nextcloud file IDs on that storage will be the same for all users, even when using log-in credentials for authentication. Includes a test to verify the ID structure.

This creates WOPI URLs that are the same across users, so collaborative editing works as expected for documents on SMB shares using log-in credentials as the authentication method.

Signed-off-by: David ddean@njstatelib.org

Fix #21049

[kesselb]

Cool 👍

Should be possible for the new test case to use a local variable.

[kesselb]

Suggested change

	$this->instance = new SMB([
	$instance = new SMB([

[kesselb]

Suggested change

	$this->assertEquals('smb::testhost//someshare//someroot/', $this->instance->getId());
	$this->assertEquals('smb::testhost//someshare//someroot/', $instance->getId());

[kesselb]

Suggested change

$this->instance = null;

[icewind1991]

While I agree that the functionality this enables is very nice to have, having them share file ids means that everything in the smb share has to be exactly the same between all users accessing the storage, including all metadata like permissions.

Simply adding this option will inevitably lead to users enabling the option where this is not the case (even if you add some warning explaining the limitations) which will lead to hard to debug unexpected behaviour.

So while I would like to have a way to get this functionality, simply adding an option to drop the username from the storageid isn't the right way to go imo.

[ddean4040]

@icewind1991 - Is there another way you can think of to get common file IDs with log-in credentials? I'm new to Nextcloud and this was just the first way that came to mind, but I'd be happy with any fix.

We're using this option for just the situation you described - to mount group shares from a Windows file server where everyone in the group has the same permissions. We assign each external storage to its user group in Nextcloud, matching the native permissions.

Without something like this we would have to disable co-editing, since users could work on the same document from an SMB share at the same time without being aware of each other, and one user's changes would be lost. Before this we also had a very bloated filecache table because of duplicate entries for each user for every file on external storage.

[juliusknorr]

We could of course just do this only in cases where global credentials are used, so when we can be sure that every user has the same access level to the files.

[icewind1991]

in that case it should already be shared, since the storage id includes the username, you only get different file ids if the username used to connect to smb is different

[ddean4040]

Hi! I keep getting pings about this and I don't know if I'm supposed to do something or what.

What we ran into is that, when you set up an external storage entry using log-in credentials under Administration, the file ID scheme makes Nextcloud think users accessing a shared file are working on different files.

There were LOTS of duplicate filecache entries, and collaborative editing didn't work as expected. Instead of working together on a document, staff thought they were working alone but were unknowingly overwriting each others' changes.

If we switch to global credentials, we essentially lose auditing on our file server, which some staff still access natively via SMB as a mapped drive. The log-in credentials option makes this hybrid access seamless, but only with some kind of fix to collapse the file IDs.

[skjnldsv]

Hi! I keep getting pings about this and I don't know if I'm supposed to do something or what.

What we ran into is that, when you set up an external storage entry using log-in credentials under Administration, the file ID scheme makes Nextcloud think users accessing a shared file are working on different files.

There were LOTS of duplicate filecache entries, and collaborative editing didn't work as expected. Instead of working together on a document, staff thought they were working alone but were unknowingly overwriting each others' changes.

If we switch to global credentials, we essentially lose auditing on our file server, which some staff still access natively via SMB as a mapped drive. The log-in credentials option makes this hybrid access seamless, but only with some kind of fix to collapse the file IDs.

There are some comments, you need to address them :)
As there is no feedback since a while I will close this PR. If you are still willing to get this in, please address the potential comments and rebase to latest master. Then, feel free to re-open.