The `occ documentserver:flush` "workaround" does not work (and cannot work) with external SMB storage; a solution idea is attached in case the root problem cannot be fixed (it has persisted for years).

The occ documentserver:flush command appears to be the "official" workaround for actually writing the content displayed in an open document to the corresponding file in the Nextcloud filesystem (an issue that has apparently existed for years).

Unfortunately, the command does not work for files stored on external storage mounted via SMB.

The reason for this is clear: the occ command (running in its own user context) lacks the credentials of the logged-in user (LDAP) required to access the SMB storage. And without those credentials, there is no access to the storage.

The issue of the differing user context is likely unsolvable; therefore, the frequently cited "workaround" can never save files to the SMB share.

The logged-in user can open and edit files using OnlyOffice and save them to the filesystem via "Save copy as." Ideally, OnlyOffice would also save the open files (in single-user mode, not multi-user!) regularly or at least upon command.

However, it does not do this, and in the scenario I described, occ documentserver:flush does not help either (for the reason mentioned above).

Is there a way or an approach to execute the aforementioned occ command (or the underlying PHP file) directly from the browser? That way, the command might have the correct user context. One would then simply need to add a link within the OnlyOffice application or the Nextcloud menu to execute the command and trigger the actual save operation.

Start by tracing the occ documentserver:flush command and its underlying PHP entry point, then compare its user context with browser-triggered requests for external SMB storage. Review the OnlyOffice save flow and determine whether a supported logged-in-user save operation is possible; done requires a validated approach that works for the described LDAP and SMB scenario.