File are not saved on file system but are only editable in onlyoffice

Hello, unfortunately we realized that Onlyoffice allows editing of documents, BUT the documents are not saved correctly on Nextcloud and always show the first version loaded. This is a serious problem which in my opinion needs to be solved because onlyoffice becomes practically useless in this way.
We should find a way to force saving the file on the file system as well. I've done some research and this seems to be a problem that has been dragging on for years.
I also carried out any test using nextcloud versions 24 and 25 but always getting the exact same result.
In various posts I have seen someone suggesting to run the occ documentserver:flush command
This actually works, BUT you should have it run every time you save a file.
I'm currently working with nextcloud 23 (apparently the most stable) onlyoffice 7.4.8 and Community Document Server 0.1.13.
If anyone has any suggestions on this I would be very grateful.
Alessandro

this is a very old issue, but still not fixed.
That's one of the reasons, Nextcloud switched to five minutes cron schedule.
But if changes happens more often, this could lead to data loss.

This is one of the reasons Nextcloud GmbH officially supports more Collabora than OnlyOffice due to lack of stability.

Just now - i'm going to open two other issues on OnlyOffice/DocumentServer

Thank You for reply, but since the occ documentserver:flush command correctly updates all files modified with OnlyOffice is it possible to schedule this command somehow?
This would solve the problem permanently and permanently.
Thanks to anyone who could figure out a solution.
Alessandro

i think, nc cron.php should do the job. check if it runs every 5 min.

Other way could be .. trigger you flush cmd via cron-job (linux crontab), according to your whish
(could be every minutes for example)

Thank you very much Githopp192 for your attention, but unfortunately I don't have the skills to compose the command. Could you be so kind as to give me more detailed information on which command to put as a cron job.

check this one:

https://opensource.com/article/17/11/how-use-cron-linux

command of course is: occ documentserver:flush

Do You mean something like that:

- - - - /usr/local/bin/[user]/public_html/[INSTALLATION FOLDER NEXTCLOUD]/cron.php occ documentserver:flush

yes , but i think you need to run occ as you apache user:

sudo -u //php ....../nextcloud/occ documentserver:flush

sorry .. did eat my cmd:

as example: sudo -u apache /bin/php /whre you nextcloud dir is/nextcloud/occ documentserver:flush

sorry .. did eat my cmd:

as example: sudo -u apache /bin/php /whre you nextcloud dir is/nextcloud/occ documentserver:flush

#minute Hour Day of Month Month Day of Week Command

(0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)

#----------------------------------------------------------------------------

I tried it but I receive this error:

/bin/bash: - : invalid option
Usage: /bin/bash [GNU long option] [option] ...
/bin/bash [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--noprofile
--norc
--posix
--protected
--rcfile
--rpm-requires
--restricted
--verbose
--version
Shell options:
-irsD or -c command or -O shopt_option (invocation only)
-abefhkmnptuvxBCHP or -o option

Mike, I'm so sorry.
I finally solved the problem and all this thanks to you.
Your suggestion was correct, but I'm on shared hosting so the command in the cron shouldn't be this:
/usr/local/bin/php -q /home/[USER]/public_html/www/[NEXTCLOUD INSTALLATION FOLDER]/occ documentserver:flush
I hope this will help others who are having the same problem.
YOU MAKE MY DAY!!!
Thank You so much
Warm regards
Ale

Ale, i'm glad you solved the issue. I whish you a wonderful day. cheers Mike

the cronjob works well for my local installation, but for the one at a hoster it doesn't synchronize the documents.
Instead I have tons of empty directories like data/appdata_*/documentserver_community/doc_*/asc*/docx_unpacked/ which is eating up my inode quota :-(

I haven't found out the reason. One difference is that the database at the hoster is still mysql 5.7 whereas the local installation is already converted to mysql 8, or it's just a different usage pattern...

As a workaround for others who see the same problem as reported here, I have found out that you can export the current version of a document within onlyoffice. Download that file and upload it again in Nextcloud, replacing the existing version. This way you have an up to date file on disk, but I know, this is an uncomfortable workaround. It would be much better if onlyoffice could synchronize the current version of the documents as they are stored in the database to disk as well.

a workaround could be to export the files after editing within onlyoffice, and one can upload the file again to the folder in nextcloud (of course one would expect that this extra step is not needed)

Hi,
I just checked the nextcloud community document server 0.1.13 on NC 26.05 and can confirm that changes are not written back to the nextcloud storage. As described above opening the same file with ONLY OFFICE again, the changes are "stored" there. opening the same file with collabora or the synced file on the laptop the old version is used.
As ONLYOFFICE is well announced
https://nextcloud.com/blog/how-to-install-onlyoffice-in-nextcloud-hub-and-new-integration-feature/
it should also work as expected.
It must also "work" without haveing access to root level occ commands as for example using a NC provider like Hetzner.

I have to amend my statement above:

the file gets updated on nextcloud after some time (minutes) but IMO must get updated immediately, especially leaving ONLYOFFICE (by selecting a different app/icon) as there is no "close" button.
ONLY OFFICE runs in FAST mode - "all changes are saved automatically" - at least here it should be mentioned "with a delay of max x minutes"

@ferdiga

Hi @ferdiga ,
as I reported before You can create e cron job set it to run every 20 sec.
The job could be something like that:
/usr/local/bin/php -q /home/[USER]/public_html/www/[NEXTCLOUD INSTALLATION FOLDER]/occ documentserver:flush
(thank ti great @Githopp192 )
Test it and let us know if it fixed the issue.
Warm regards
Ale

As I said, I have no access to the root account on the Hetzner service - hence I (and all other Hetzner and SaaS users) can not do what you ask for.

@ferdiga

Hi @ferdiga ,
I know it's not a conventional operation, and in some cases it could put the server under stress, but you could try writing a php script like the following:

<?php
while (true) {
    // do something

    // wait  20 second before running the next iteration
    sleep(20);
}
?>

and have it run every 20 seconds.
Unfortunately I can't think of any other alternatives.
Warm regards
Ale

It would be very helpful to know the timespan after which the document server "saves" the file.
It's about managing expectations.

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 60 days. Thank you for your contribution!

Retaking repo management include inheritance of old, not treated, and probablty obsolete issues, this is why it was decided to mark issues as stale.

This issue has been closed due to inactivity. If you feel this is in error, please reopen the issue or file a new issue with the relevant details.

Fixed for v0.4.0, by #396. You were right that occ documentserver:flush was not a solution — and running it on every save would have had its own problem, which is #398.

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.

Navigation Menu

Repository navigation

File are not saved on file system but are only editable in onlyoffice #281

(0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

File are not saved on file system but are only editable in onlyoffice #281

Description

Activity

Githopp192 commented on Dec 1, 2022

phaser32 commented on Dec 1, 2022

Githopp192 commented on Dec 1, 2022

phaser32 commented on Dec 1, 2022

Githopp192 commented on Dec 1, 2022

Githopp192 commented on Dec 1, 2022

phaser32 commented on Dec 1, 2022

Githopp192 commented on Dec 1, 2022

Githopp192 commented on Dec 1, 2022

Githopp192 commented on Dec 1, 2022

Githopp192 commented on Dec 1, 2022

(0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)

phaser32 commented on Dec 1, 2022

phaser32 commented on Dec 1, 2022

Githopp192 commented on Dec 1, 2022

mrbaseman commented on Dec 5, 2022

1 remaining item

mrbaseman commented on Dec 11, 2022

ferdiga commented on Oct 16, 2023

ferdiga commented on Oct 16, 2023

phaser32 commented on Oct 16, 2023

ferdiga commented on Oct 16, 2023

phaser32 commented on Oct 16, 2023

ferdiga commented on Oct 16, 2023

github-actions commented on Oct 21, 2024

github-actions commented on Dec 23, 2024

chadek commented on Sep 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions