Collaborative file locks are not shared between users accessing the same SMB external storage with user-specific credentials

[mromite]

Description

When the same SMB external storage is mounted by an administrator and made available to multiple Nextcloud users, each user receives a different Nextcloud fileid for the same physical SMB file if user-specific/session credentials are used.
As a consequence, Collaborative File Locking (files_lock) does not propagate manual or automatic locks between users.
This creates a potentially dangerous situation: the Nextcloud Desktop client displays a padlock when a Microsoft Office file is opened locally, but another user accessing the same physical file through Nextcloud does not see the lock and can open or modify the file.

Environment

• Nextcloud Server: 34.0.3.2
• Collaborative File Locking (files_lock): 34.0.1
• Nextcloud Desktop client: 34.0.3
• Operating system: Ubuntu 26.04
• PHP: 8.5.4
• Database: PostgreSQL 18.4
• External storage: SMB/CIFS
• SMB server: NAS at 192.168.60.60
• External storage configured once by an administrator and assigned to multiple users
• Users involved: Mario and Karms

Steps to reproduce

1. Configure an SMB/CIFS external storage through the Nextcloud administration interface.
2. Select a user-specific authentication mechanism, such as session/login credentials.
3. Make the same external storage available to two Nextcloud users.
4. Synchronize the external storage using Nextcloud Desktop.
5. Open an .xlsx or .docx file locally as the first user.
6. Observe that Nextcloud Desktop displays a padlock on the file.
7. Log in to the Nextcloud web interface as the second user.
8. Open the same SMB folder and inspect the same physical file.
   The second user does not see the lock.
   The issue can also be reproduced without the Desktop client:
9. Manually lock the SMB file through the Nextcloud web interface as the first user.
10. Log in as the second user.
11. Inspect the same physical file.
    The manual lock is still not visible to the second user.

Diagnostic results

Both users access the same physical SMB file through the same external storage configuration, ID 4.
However, occ info:file returns different Nextcloud file IDs.
For Mario:
CommonFile_Test.xlsx
fileid: 38264
size: 42 KB
etag: 6a96f90c6ae51
mounted at: /Mario/files/OurShare/
external storage id: 4
external type: SMB/CIFS (Windows network share)
For Karms:
CommonFile_Test.xlsx
fileid: 68638
size: 42 KB
etag: 6a8f49cb515c7
mounted at: /Karms/files/OurShare/
external storage id: 4
external type: SMB/CIFS (Windows network share)
The physical file, size, modification date and SMB storage are the same, but Nextcloud assigns different fileid and etag values.
The external storage verification from the CLI returns:
status: indeterminate
code: 2
message: No login credentials saved
This is consistent with credentials being stored in the individual user session.

Workaround and confirmation

A second SMB external storage, ID 9, was configured using Global credentials and made available to the same users.
After this change, both users received the same Nextcloud file ID and ETag for the physical SMB file.
For both Mario and Karms:
CommonFile_Test.xlsx
fileid: 165750
size: 42 KB
etag: 6a97f9b71f23e
external storage id: 9
external type: SMB/CIFS (Windows network share)
The output also correctly lists all users with access:
Mario
Karms
Next_admin
With Global credentials, manual and automatic locks are correctly visible between users.
Actual behaviour
• Each user-specific SMB connection creates a separate Nextcloud file object.
• The same physical file receives different fileid values.
• Locks are associated only with one user’s fileid.
• Other users do not see or respect the lock.
• Nextcloud Desktop still displays a padlock to the user opening the file, which gives the impression that concurrent editing is prevented.
• Concurrent editing can therefore produce conflicts or data loss.

Expected behaviour

Ideally, Nextcloud should identify that users are accessing the same physical object on the same SMB server/share and associate the collaborative lock with the underlying SMB object rather than only with the per-ujser Nextcloud fileid.
If sharing locks across user-specific SMB connections cannot be implemented, Nextcloud should at least:

1. Display a prominent warning in the External Storage administration interface when a user-specific authentication mechanism is selected.
2. Explain that collaborative and automatic file locking will not work across users.
3. Avoid presenting the Desktop client padlock as a shared lock when it only applies to the current user’s file object.
4. Warn users that another Nextcloud user may still modify the same physical SMB file.
5. Consider disabling automatic collaborative locking for this configuration or displaying it as a local-only lock.

Impact

This is particularly important in business environments where:
• large existing SMB archives are exposed through Nextcloud;
• different NAS credentials and ACLs are used for individual users;
• Microsoft Word and Excel files are synchronized locally;
• users rely on the displayed padlock to prevent concurrent editing;
• moving millions of existing files into native Nextcloud storage is not practical.
The current behaviour forces administrators to choose between:
• preserving individual SMB/NAS permissions; or
• obtaining reliable cross-user collaborative locking through Global credentials.
A clearer warning or a server-side solution would prevent administrators and users from relying on a lock that is not actually shared.