Admin-configured shared SMB storage with user-specific credentials does not propagate changes between users

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Nextcloud 27.0.0
Desktop client 3.9
Server OS Ubuntu 22.04

Users from Active Directory
Integration of external SMB share (Share1) on Server 2012
Credentials stored in the database.

User A and User B have mounted Share1 (as a virtual file system).

User A creates files through the browser or uploads them using the desktop client.
Both users have the desktop client running, but User B does not receive the new files. User B is unaware that data has been created.

Only when User B forces synchronization are the new files created.
It is expected that when User A or User B creates a file on the share, all users who have access to the share will be notified.
In both cases, the upload is done through the Nextcloud server, and it should inform all clients that a file has been created. However, the server does not push notifications to the clients, and the client itself does not check if there are any new files.

Finally, User B has the files and modifies one of the text files.
The server sends the file to User B, who makes changes, and the modifications are transferred.

User A is not aware of these changes, so the timestamp for the modification date remains unchanged for User A.
Currently, the file exists only in the cloud.
User A tries to download the file, receives an error message, and cannot download it.
Now User A also has the latest version of the file!
User A makes a modification, and the current version is transferred to the server.
However, User B is not notified of any changes made by User A.
User B still has the local version and is not informed about the modification made by User A.

Even with a forced synchronization, there is no file comparison with the server.
Worse still, User B can now modify and save their local file, which would be uploaded again and overwrite the file on the server!

This issue related to integrated Windows shares has been present since Nextcloud version 13 (possibly even 12).
The communication between the desktop client and the server is insufficient, and changes are not propagated to all relevant users.
I suspect this problem also affects other external shares that are not integrated within a fixed user context.

The solution, in theory, seems simple.
The server transfers data from User A to User B, so it should also know which groups/users can access the share and trigger a push sync for all users when a file is modified.
If User A modifies a file in the browser, their desktop client should immediately sync the changes!

Then, User B logs into the browser, and the file modification is immediately synced!

Now, User A makes a modification using the desktop client, and the changes are uploaded to the server.
User B is still logged into the browser, but the timestamp in their view does not change!!!
If User B now accesses the file in the browser, the server establishes a direct connection to the current version on the file server for User B, and the real version is loaded and then synced to the client.

This means that Nextcloud does not update the timestamps in its database for files located on external shares when modified by a user.
Only the user who made the modification sees the change updated in the Nextcloud database, but nothing happens for all other users who have access to the same share.
This behavior is a major problem.
On the one hand, the browser display in terms of timestamps is unreliable, and on the other hand, working with the desktop client is dangerous! (Dangerous because users can overwrite each other's work without being aware that they are destroying or having their work destroyed by others.)
When working in the browser, at least the current version is always loaded from the server at the time of access/download.
The Nextcloud server is

not supposed to register changes on the Windows file server that were not initiated through the Nextcloud server. However, for all changes that occur through the Nextcloud server, the modifications should be propagated to all users and clients.
The basic process actually works, otherwise User A's desktop client would not immediately sync data when User A modifies data through a browser.

Theoretically, there should be no need to check if the user is allowed to view the file on the file server; the file server will deny access if the user is not authorized.
Since the valid credentials for the share are also stored in the Nextcloud database, and the upload and sync work through the desktop clients without being logged into the browser, the Nextcloud server could proactively check for changes in the shares whenever it detects that a user has made changes in the share.

Nextcloud is a great product, but it only works reliably when the data is stored locally on the Nextcloud server, preferably organized within group folders.
If the reliability regarding external shares on Windows servers were improved, it would greatly enhance usability.

Steps to reproduce

1. Nextcloud 27 + LDAP + AD-Server + Windows File Server with shares, etc.
2. Windows share added as an External Share: Credentials stored in the database.
3. Desktop client installed and set up for Users A and B.
4. User A creates a file.
5. User B has to force a sync in order to see the new file.
6. User A modifies the file.
7. User B does not receive the file changes! (Even forcing a sync does not help.)

Expected behavior

It is expected that when using External Shares on a Windows server and storing login credentials in the database, changes made to files by User A will also be passed on to User B.

Both User A and User B access the same External Share (using their own login credentials).
If User A makes a modification, User B should also be notified, meaning the data needs to be synced, and timestamps should be consistent across all users and applications.

Installation method

None

Nextcloud Server version

27

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Apache (supported)

Database engine version

PostgreSQL

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "testcloud.domäne.de",
            "testoffice.domäne.de",
            "192.168.0.1",
            "192.168.2.1",
            "127.0.0.1"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "skeletondirectory": "",
        "overwrite.cli.url": "https:\/\/testcloud.domäne.de:443",
        "dbtype": "pgsql",
        "version": "27.0.0.8",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "ldapIgnoreNamingRules": false,
        "ldapProviderFactory": "\\OCA\\User_LDAP\\LDAPProviderFactory",
        "maintenance": false,
        "theme": "",
        "loglevel": 2,
        "trashbin_retention_obligation": "7,14",
        "versions_retention_obligation": "7,14",
        "cache_chunk_gc_ttl": 86400,
        "integrity.check.disabled": true,
        "onlyoffice": {
            "verify_peer_off": true
        },
        "updater.release.channel": "stable",
        "app_install_overwrite": [
            "spreed",
            "occweb",
            "keeweb",
            "sharelisting",
            "polls",
            "files_clipboard",
            "breezedark",
            "issuetemplate",
            "groupfolders",
            "onlyoffice",
            "files_linkeditor"
        ],
        "encryption.legacy_format_support": false,
        "encryption.key_storage_migrated": false,
        "default_language": "de",
        "default_phone_region": "de",
        "default_locale": "de",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "updater.secret": "***REMOVED SENSITIVE VALUE***"
    }
}

List of activated Apps

Enabled:
  - activity: 2.19.0
  - admin_audit: 1.17.0
  - calendar: 4.4.2
  - circles: 27.0.0
  - cloud_federation_api: 1.10.0
  - comments: 1.17.0
  - contacts: 5.3.1
  - contactsinteraction: 1.8.0
  - dashboard: 7.7.0
  - dav: 1.27.0
  - deck: 1.10.0
  - federatedfilesharing: 1.17.0
  - federation: 1.17.0
  - files: 1.22.0
  - files_external: 1.19.0
  - files_markdown: 2.4.1
  - files_pdfviewer: 2.8.0
  - files_rightclick: 1.6.0
  - files_sharing: 1.19.0
  - files_trashbin: 1.17.0
  - files_versions: 1.20.0
  - firstrunwizard: 2.16.0
  - groupfolders: 15.0.0
  - issuetemplate: 0.7.0
  - logreader: 2.12.0
  - lookup_server_connector: 1.15.0
  - nextcloud_announcements: 1.16.0
  - notifications: 2.15.0
  - notify_push: 0.6.3
  - oauth2: 1.15.0
  - occweb: 0.1.0
  - password_policy: 1.17.0
  - photos: 2.3.0
  - privacy: 1.11.0
  - provisioning_api: 1.17.0
  - recommendations: 1.6.0
  - related_resources: 1.2.0
  - serverinfo: 1.17.0
  - settings: 1.9.0
  - sharebymail: 1.17.0
  - sharelisting: 1.1.1
  - smb_test: 0.3.7
  - support: 1.10.0
  - survey_client: 1.15.0
  - systemtags: 1.17.0
  - text: 3.8.0
  - theming: 2.2.0
  - twofactor_backupcodes: 1.16.0
  - updatenotification: 1.17.0
  - user_ldap: 1.17.0
  - user_status: 1.7.0
  - viewer: 2.1.0
  - weather_status: 1.7.0
  - workflowengine: 2.9.0
Disabled:
  - apporder: 0.15.0 (installed 0.15.0)
  - bruteforcesettings: 2.7.0
  - documentserver_community: 0.1.13 (installed 0.1.13)
  - encryption: 2.15.0
  - event_update_notification: 2.2.0 (installed 2.2.0)
  - extract: 1.3.5 (installed 1.3.5)
  - files_clipboard: 0.7.1 (installed 0.7.1)
  - files_linkeditor: 1.1.14 (installed 1.1.14)
  - mail: 3.2.1 (installed 3.2.1)
  - metadata: 0.18.0 (installed 0.18.0)
  - onlyoffice: 8.0.0 (installed 8.0.0)
  - polls: 5.0.5 (installed 5.0.5)
  - spreed: 17.0.0 (installed 17.0.0)
  - suspicious_login: 5.0.0
  - tasks: 0.15.0 (installed 0.15.0)
  - twofactor_totp: 9.0.0
  - user_saml: 5.2.0 (installed 5.2.0)

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

Reproduce the issue with Nextcloud 27, the files_external SMB share, LDAP/Active Directory, and desktop clients for Users A and B using the listed steps. Investigate how server-side changes on a shared external share reach other users and clients, including the notify_push path. Done means changes and timestamps propagate reliably to every authorized user without stale local files overwriting newer server content.