Edits and changes made in Onlyoffice are not synced into Nextcloud

@googol42

Issue

Edits and changes made in Onlyoffice are not saved into Nextcloud and the next sync from Nextcloud to Onlyoffice destroys all changes made in Onlyoffice. This results in loss of work.

Expected Behavior

Edits and changes written in Onlyoffice sync to the local desktop environment and the changes done in the desktop environment sync to OnlyOffice

Actual Behavior

Files stored in the local desktop environment are synced flawlessly to Nextcloud. Onlyoffice opens them flawlessly and lets the user edit the document. After saving the document and or logging out from nextcloud changes are kept in OnlyOffice cache and never written to the actual document. When user opens same document from the desktop the changes have disappeared. If user saves the document with a small change, this change is synced to OnlyOffice overwriting the changes in the cache.

Possible Fix

Write cache data to file regularly and frequently. Recognize when user leaves Onlyoffice or closes file and write cache to file. In short: Copy the functionality of Google Docs.

Steps to Reproduce

Use a desktop wordprocessor and create a document in a NextCloud synced folder in your desktop environment
Log onto the Nextcloud web UI and open the file with OnlyOffice.
Ask colleague to do the same
Make changes in document
Exit document
Open document with desktop wordprocessor from local NextCloud synced folder.
Notice that the changes never were saved to the file in NextCloud,.
Open file in OnlyOffice from the Nextcloud web UI to notice changes are still there
Close OnlyOffice
Make minimal change in the desktop wordprocessor and save file locally.
Let NextCloud sync
Open file in OnlyOffice from the Nextcloud web UI to notice all changes made in OnlyOffice have been lost and overwritten with those made in the desktop environment
Feel despair.

Context

We just lost 2 days worth of expensive work made by our consultant. This is becoming very expensive to us!

Your Environment

Nextcloud 18.0.3
OnlyOffice Community Server bundled with NextCloud 18
Nextcloud desktop client 2.6.4 Linux
Nextcloud desktop client 2.6.4 Mac

Edit:
Tried also this cronjob proposed by @googol42 but it does NOT solve the issue

- - - - php -f /var/www/yourdomain/occ documentserver:flush

The onlyoffice integration as it is now is not suitable for production. DO NOT USE IT, YOU WILL LOSE DATA. I do not know who to tag to get attention to this? This bug is causing economic losses at the monent.

Just got a mail from our consultant. She never opened the file from the desktop, only using Onlyoffice from our server. Seems like the data in the onlyoffice cache is never written to Nextcloud. The "Save as" function saves to cache, but the cache never gets written to Nextcloud. User gets false secure feeling about having backed up data while in real life it is stored in cache and lost.

See #78, #77, #12, #87 all reporting the same issue.
I think we should try to get in touch with Nextcloud team directly. Any clue how to reach them?

@skjnldsv

@skjnldsv could you lead us to the right contact to raise awareness?

@icewind1991

Of course!
@icewind1991 @rullzer @nickvergessen @blizzz :)

IIRC it requires the tab to be closed so OO writes back the changes. It is by design of the OO backend however. I am not really involved there though.

I tried closing in various ways, could it be related to autosaving or fast collaboration? (See "Advanced settings..." in File tab.

In case of multiple users, does the writeout happen after any user closing the tab or the last user closing the tab?

My documents are saving on a normal cron-run. Not sure how often I can run cron though, every minute would be good for saving the documents (my current settings are for every 5 minutes):

*/5 * * * * php -f /var/www/nextcloud/cron.php

Mine are NOT saving on normal cron run.

IIRC it requires the tab to be closed so OO writes back the changes. It is by design of the OO backend however. I am not really involved there though.

Who would be involved? It would be good to get the attention of a person who can fix this before more damage is caused.

None of the cron settings leads to a working setup. However, I also cannot view the logs. I'm on a hosted environment (Hetzner, Germany), not sure if that makes a difference?

@icewind1991

@icewind1991 @rullzer @nickvergessen @blizzz What should we do to get this tagged as a bug? Us discussing here does not contribute to much.

Should be solved in next v0.4.0 release

Will this fix also work when using SMB shares (session-based credentials or Apache Kerberos)?

Opening and editing documents on such shares works perfectly, as does "Save Copy As"—meaning the latter command is presumably executed within the user context (using the session credentials), otherwise the copy wouldn't be saved to the SMB share.

How should I envision the announced change regarding "saveSnapshot()"? Will the saving process (whether automatic, forced, or manual) also be executed in the user context, thereby allowing it to utilize the session credentials for SMB access?

Given that Nextcloud has for years allowed this project to lose large amounts of user data, i would advise not using this project for anything you care about.

…

On 12 September 2026 13:45:10 CEST, yummiweb ***@***.***> wrote: yummiweb left a comment (nextcloud/documentserver_community#100) > Should be solved in next v0.4.0 release Will this fix also work when using SMB shares (session-based credentials or Apache Kerberos)? Opening and editing documents on such shares works perfectly, as does "Save Copy As"—meaning the latter command is presumably executed within the user context (using the session credentials), otherwise the copy wouldn't be saved to the SMB share. How should I envision the announced change regarding "saveSnapshot()"? Will the saving process (whether automatic, forced, or manual) also be executed in the user context, thereby allowing it to utilize the session credentials for SMB access? -- Reply to this email directly or view it on GitHub: #100 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

It should also be noted that the fix has at least partially been written with AI tools. I don't trust it either.

Leave expired sessions out of a document's participants

Make the onlyoffice settings take effect: formats and the Save button (…

Fixed for v0.4.0, by #396. This issue is five and a half years old and it was the right diagnosis all along — including the "possible fix" in the first post, which is close to what was done.

What was wrong. The editor's "all changes are saved" meant the changes had reached this server's database, not that they had reached the file. Nothing wrote the file until the last participant had left and the Cleanup background job had run. On an instance whose cron is slow, misconfigured, or set to AJAX, a document could be edited all day with nothing on disk — and a browser closed at the wrong moment lost the lot. Worse, the server never noticed an editor leaving at all: a document server that holds a WebSocket learns of it from the socket closing, but this one is polled over HTTP, so the pending poll was simply dropped and nothing ran to notice.

What changed (#396, and #387 for the session accounting):

While you are editing. A save writes the document out if it has been longer than autosave_interval (60 s by default, 0 turns it off) since the last write — from the editing path itself, not from the background job. It costs one document assembly per interval per document being edited, however much is typed in between, and none at all while nobody is typing.
When the last editor leaves. The editor says goodbye on its way out and the server acts on it: the session ends, the people still in the document are told, and if that was the last participant the document is written and disposed of immediately. Two paths, because sdkjs only covers one: its own close command, and a beacon sent by the page hosting the editor frame (it has to be the host page — a request started by a frame that is being detached is cancelled with it).
Expired sessions no longer count as participants. Rows were only deleted by the background job, so between two runs the table held every session that had ever stopped polling. Counting those meant a document was never seen to be empty, and the write fell back to whenever the job next ran — which is the wait this issue is about.
The background job still runs, and now writes documents that are being edited instead of skipping them, so it still catches a browser that crashed or a server restarted mid-edit. It is no longer what saving depends on.

To change the interval:

occ config:app:set documentserver_community autosave_interval --value=120

Proof. Two regression tests, driving real editors in headless chromium and reading the file on disk after each step — no cron, no occ documentserver:flush anywhere in the run. Against master just now, Nextcloud 34, ONLYOFFICE connector 10.1, bundled Euro-Office 9.3.4:

tests/rig/autosave_test.py — the file is written while the document is open:

==> [1] type AUTO485531, nothing else
   file: {'AUTO485531': True} | doc folders: 1 | changes: 71

==> [2] type AUTO485532 straight away, inside the 45s interval
   file: {'AUTO485531': True, 'AUTO485532': False}

==> [3] wait out the interval, then type AUTO485533
   file: {'AUTO485531': True, 'AUTO485532': True, 'AUTO485533': True}

==> [4] type AUTO485534 and close the editor
   closing: destroyEditor()
   file: {'AUTO485531': True, 'AUTO485532': True, 'AUTO485533': True, 'AUTO485534': True}
   doc folders: 0 | changes: 0 | sessions: 0

   VERDICT: saving during editing works
-- autosave: PASS in 183s

Step 1 is the whole issue: the text is in the Nextcloud file seconds after being typed, with the document still open. Step 2 is the cost control — a save inside the interval must not re-assemble the document. Step 4 is closing the editor: everything is in the file and the document is disposed of on the spot.

tests/rig/leave_test.py — two participants, and nobody runs anything:

==> [1] both type
   sessions: 2

==> [2] A closes the editor while B is still in the document
   A closing: destroyEditor()
   sessions: 1 | doc folders: 1 | changes: 158

==> [3] B keeps typing, and it still reaches the file
   file: {'LEAVE49059-A1': True, 'LEAVE49059-B1': True, 'LEAVE49059-B2': True}

==> [4] B types once more and closes the tab
   file: {'LEAVE49059-A1': True, 'LEAVE49059-B1': True, 'LEAVE49059-B2': True, 'LEAVE49059-B3': True}
   doc folders: 0 | changes: 0 | sessions: 0

==> [5] reopen the document: the editor must show what was typed
   markers missing from the reopened document: none

   VERDICT: leaving a document saves it
-- leave: PASS in 284s

Step 2 is the other half of it — one person leaving must not end the document for everybody else — and step 5 reopens the file and asks the editor's own document model what it displays, rather than trusting the write.

The whole suite is green on master as of this comment: formats, smoke (every format opens, edits and reaches the file), flush-live, autosave, leave, twotab, coedit, coedit-xlsx, forcesave, chat. It runs in CI on pull requests and weekly, so this does not quietly regress again.

An LLM slop fix is a fitting twist to this entire sordid story

An LLM slop fix is a fitting twist to this entire sordid story

What do LLMs do best? What were they originally built for?
Language processing. And they have become exceptionally good at that.

They can not only read and draft texts but also structure their content. They can do all this based on an existing text or simply from a given idea.

They can do the same when translating between languages—a task they now perform with great precision.

Now tell me: Which of the aforementioned activities isn't part of "programming"? It is essentially the same thing.

These models "speak" various languages—including programming languages—and essentially just translate between human-formulated requirements (which include clearly stated error descriptions) and the "code."

While a programmer might lose the big picture (knowing the general structure but forgetting specific details), an AI can easily retrieve every detail whenever necessary. This is incredibly helpful for debugging; an AI often spots logic or syntax errors much faster.

However, there are both upsides and downsides to this:

A programmer is aware of their code's complexity and is very cautious about making changes—especially far-reaching ones. This can lead to a reluctance to touch certain parts of the code, even when restructuring is urgently needed (since program structures can sometimes evolve into dead ends). Consequently, problems remain unsolved or bugs go unfixed; not infrequently, errors are denied or dismissed as intended behavior. But hey, that’s "normal" human behavior, and we are all "only" human.

An AI, on the other hand, has no qualms about modifying or restructuring large sections of code to achieve its goal (improving the code or satisfying the user). This increases the likelihood of code evolution and bug fixes, but it also carries the risk of introducing new problems through those changes. I agree with all the critics on that point. However, these kinds of errors can be pointed out and subsequently fixed. Essentially, you have to stay closely involved in the process; if you do, the result can be excellent.

The developer is thus increasingly shifting from manually writing and typing code to defining the desired workflow structure, program logic, and other requirements—effectively becoming, in a sense, the overseer of "their" code or project. In other words, they become more of a project manager than a developer—but that isn't necessarily a bad thing.

3500 line change, 3000 words in the pull requests not even counting the walls of text in the commit messages. Surely someone is going to review all of that very thoroughly.

This project has been stuck for years, almost 5 to 6 years now. It was only still kind of usable because I volunteer to maintain it when nobody else wanted to. Without AI help, framed with real testing and automated regression ones on a real test rig, I would have never been able fix even one of this long standing issues. AI is a tool, it can be stupid, but still, it helps going forward where tasks are being huge.

Facts will talk by themselves, was it broken before? Yes, will it be worst afterward? Hopefully and probably not. Any constructive feedback will be welcome and as always, any PR is appreciated especially if it is not AI code

This project has been stuck for years, almost 5 to 6 years now. It was only still kind of usable because I volunteer to maintain it when nobody else wanted to. Without AI help, framed with real testing and automated regression ones on a real test rig, I would have never been able fix even one of this long standing issues. AI is a tool, it can be stupid, but still, it helps going forward where tasks are being huge.

Thanks for taking the initiative!

I can't run full test scenarios.

As an (administrative) user, there isn't really anything more I can contribute to a project like this—other than reporting bugs (or what appear to be bugs) in a structured way and perhaps sharing ideas.

However, it’s always helpful to know whether error reports are being taken seriously (or even read at all); otherwise, people aren't inclined to put in the effort.

I don't know what the situation was like here before, but for the moment, I'm quite optimistic.

@chadek

@chadek I don't think people blame you for using AI. Its more like they make fun of the onlyoffice developers ignoring this issue and then someone from the outside solving it.

With my very limited knowledge it looks like quite a complicated fix with the deeper issue being a fundamental structural problem about how onlyoffice handles the "source of truth". Diverging states are always a mess and there is a reason that pretty much all file sharing solutions ask the user to resolve the issue manually instead of assuming something.

For example Onlyoffice never asks the user whether "to reload from nextcloud of overwrite the version inside nextcloud with the current one". By trying to "keep the software simple" and "keeping complicated things away from the user" they inevitably created unpredictable behavior.

And this is not an isolated issue, it is a fundamental one within the enterprise software area. Functionality, flexibility and consistency is sacrificed for gamification, simplification and hiding things from the user due to the fear of confusing them. And unfortunately the users have internalized this as their own expectation.

Computer used to be a tool to accelerate a process, now they are their own ends in themselves.

Navigation Menu

Repository navigation

Edits and changes made in Onlyoffice are not synced into Nextcloud #100

Issue

Expected Behavior

Actual Behavior

Possible Fix

Steps to Reproduce

Context

Your Environment

272 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Edits and changes made in Onlyoffice are not synced into Nextcloud #100

Description

Issue

Expected Behavior

Actual Behavior

Possible Fix

Steps to Reproduce

Context

Your Environment

Activity

timo12357 commented on Mar 26, 2020

cju77 commented on Mar 26, 2020

timo12357 commented on Mar 26, 2020

fabiangebert commented on Mar 26, 2020

timo12357 commented on Mar 26, 2020

skjnldsv commented on Mar 26, 2020

blizzz commented on Mar 26, 2020

fabiangebert commented on Mar 26, 2020

timo12357 commented on Mar 26, 2020

p-jo commented on Mar 26, 2020

timo12357 commented on Mar 26, 2020

timo12357 commented on Mar 26, 2020

fabiangebert commented on Mar 26, 2020

timo12357 commented on Mar 27, 2020

272 remaining items

yummiweb commented on Sep 12, 2026

shibco commented on Sep 12, 2026

ccoenen commented on Sep 13, 2026

chadek commented on Sep 15, 2026

shibco commented on Sep 15, 2026

yummiweb commented on Sep 15, 2026

ccoenen commented on Sep 15, 2026

chadek commented on Sep 15, 2026

chadek commented on Sep 15, 2026

yummiweb commented on Sep 15, 2026

ClundXIII commented on Sep 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions