onlyoffice co editing

hi @ all

so i have installed next cloud snap and also installed only office from within the app with the community server, i have added the path for only office https://test/index.php/apps/documentserver_community/ within the only office app disable cert verification .

Now my problem is the co editing it seems that then i create a new lets say excel file and share it so both users co edit ,having everything correct meaning the settings for that when user1 types in the file user 2 dont get any data but for a strange reason it can see where user1 points its mouse with in the file.So no data at all.

is there something else i am missing ? also when trying to print the file it always saves it to pdf unless you choose to safe it in other type and always the downloaded file is empty meaning the pdf !

can please anyone provide for an answer i am willing to pay for the fix !!!!i need co editing !

well im guessing nobody knows !!!

I'm having the same issue. Cursor of co-editors is displayed but changes aren't visible until the document is closed and opened again.
Tried different browsers, co-editing settings etc. to no avail.
I had the same problem on two different nextcloud installations.

I have the same problem.

well since no one did actually gave an answer i could not find how to fix that issue i had to install only office as stand alone, i suggest you do the same you can install it on the same server you already have next cloud also choose the easy way the automatic way snapd ...since then all is good !

i tryed but i did not managed to, can you explain how did you do please ??

Same error. Since few months and last updates (snap auto-update), co edition doesn't work anymore

The same problem exists also on the HETZNER.de StorageShare servers, running nextcloud 26.0.3.
Unfortunately, this makes collaborative editing not only difficult but also dangerous, because one user can overwrite the other user's cells or text without even realizing.

same here. Anybody any idea where to check for some debugging info?

We Hello, we are experiencing a similar problem

we installed a Nextcloud to share office files in collaborative mode
OnlyOffice + Documentserver Community
We tested for 2 people only.

Simultaneous editing of a spreadsheet between 2 users works but the modifications in real time are not visible to both of them respectively.
In fact, changes made by one can overwrite changes made by the other.
Likewise, creating new tabs in the same file are not visible.

On previous versions of Nextcloud, I am sure I have already made it work and a priori, the interest of OnlyOffice+DocumentServer on Nextcloud is precisely to allow this collaborative editing so I am surprised by the problem.

I repeated this test on 3 different Nextcloud instances and I obtained exactly the same result/problem.

I'm thinking of a bug linked to the update in version 27.1.0 of Nextcloud or a missing PHP library.

Has anyone come across this problem before ?
Do you have a line of investigation?

NB:
The nextcloud is installed on a VMWare virtual machine. This is an installed and upgraded TurnkeyLinux iso.
Apache Server
Php 8.2 version
Nextcloud version: 27.1.0

Thank you in advance for your help.

Same issue on:
Apache Server
Php 8.2.22 version
Nextcloud version: 29

Same here on Nexcloud 29.0.6 and CDS 0.1.18 and OO 9.4.0.

@chadek

@chadek any news ?

we also need a fix...

@Jerome-Herbinet

@Jerome-Herbinet it is not an easy fix and I'm really not skilled enough with php to fix that on my own, I need help. I think it could be something related to web socket leading to several kind of issue. More details on this closed issue here. I think the way to fix that is to get websock working properly and at the same time work on making newer onlyoffice version available as we are currently stuck at 7.2.X. Please follow up on this issue any input would be very welcome

@Jerome-Herbinet

@Jerome-Herbinet this is normally fix, any feedback is welcome before closing this

The problem persists and has even worsened.

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, this command destroys more than it helps at the moment:
Community Document Server - Version 0.3.2
ONLYOFFICE - Version 10.1.2,

...so be warned:

#398

What you describe is the content of #398 and some work on that is to come with 0.4.0. I hope it fixes everything or at least most of it. My "testing" server got offline, it's been back today, I might be able to continue my work on that soon.

Any feed back on the co-edition experience (taking appart saving issue is welcome)

Co-authoring works now, and v0.4.0 is where I would say it is actually fixed rather than mostly working.

What was wrong. Two separate things, and your description — "partner B sees which cell, but never sees what is added" — is precisely the first one. Cursor and selection messages were reaching the other browser; the changes were not being displayed. The broadcast this server sends when someone saves a batch of changes was missing the chunk flags sdkjs uses to decide whether a batch is complete, so the receiving editor buffered every batch forever and rendered none of it. Everything looked right on the wire. That was fixed in v0.3.2/v0.3.3.

What v0.4.0 adds is the reliability the first fix exposed:

a second participant no longer takes the document away from everyone. sdkjs sends a close command from DocsCoApi.disconnect() whenever an editor drops to view mode with the page still open — a licence verdict on the number of users in a document, rights being taken away, disconnectEveryone, a critical error — and this server was treating that as "the editor was closed": it removed the session and, when it was the last one, wrote the document out and deleted its folder, underneath a page that was still editing. Everything that session did afterwards then replayed against a baseline that had been thrown away. The command is advisory now.
a batch of changes that collides on change_index is retried. Two co-authors saving at the same moment aimed for the same indexes; the loser got an integrity-constraint violation thrown out of a transaction nobody closed, which left the connection in a dead transaction, so every later query in that request failed with SAVEPOINT DOCTRINE_n does not exist — the session's saves kept failing after the collision, not just the one that raced. Measured on the rig with four processes writing to one document: before, 38 of 120 changes stored and 41 of 60 batches failed; after, 120 of 120, no duplicates, no gaps, no failures.
the memcache IPC backend no longer loses an in-flight message. A reader could claim a slot whose payload had not been written yet, return nothing, and make that message unreachable for good while everything queued behind it moved up a place. That one only bites instances with memcache.distributed set, which is most of the bigger ones.

Proof. tests/rig/coedit_test.py drives two headless browsers, logs a different user into each, opens the same file in both, types in each, and then asks each editor's own document model what it displays — not whether the messages were sent. Against master just now, Nextcloud 34, connector 10.1, bundled Euro-Office 9.3.4:

===== LIVE PROPAGATION =====
   A sees: '... FLUA2 \r\n A1 \r\n TABB2 ...'
   A: all 4 markers present
   B sees: '... FLUA2 \r\n A1 \r\n TABB2 ...'
   B: all 4 markers present
   VERDICT: live co-authoring OK

>>> session A (admin): 1 socket session(s) established -> ['f3836787d018719a']  (more than one means it reconnected mid-edit)
>>> session B (bob): 1 socket session(s) established -> ['2f605963220164cf']  (more than one means it reconnected mid-edit)
-- coedit: PASS in 197s

And the same in a spreadsheet, which is the case you both reported — changes there carry recalculation indexes and used to be the worse of the two:

   A sees: 'U61=XA1  | U67=XB1 '
   A: all 2 markers present
   B sees: 'U61=XA1  | U67=XB1 '
   B: all 2 markers present
   VERDICT: live co-authoring OK
-- coedit-xlsx: PASS in 140s

tests/rig/twotab_test.py covers the second-participant case, including one of them being dropped to view mode:

==> round 2
   A co-auth: {"isCoAuthoring":true,"countEditUsers":2,"bufferedChunks":0,"bufferedOther":0,"changesIndex":318,...}
   B co-auth: {"isCoAuthoring":true,"countEditUsers":2,"bufferedChunks":0,"bufferedOther":0,"changesIndex":318,...}
   tab A is missing: nothing
   tab B is missing: nothing

==> tab B is dropped to view mode (what sdkjs does on a licence verdict, rights change or disconnectEveryone)
   doc folders: 1 | changes: 318 | sessions: 2
   A types on, and it must still reach the file
   file: {'TAB49343-A9': True}

   VERDICT: two tabs co-author
-- twotab: PASS in 269s

bufferedChunks: 0 and bufferedOther: 0 are the numbers that were non-zero and growing when this was broken: that is sdkjs holding changes it had received and would not render.

Both tests run in CI on pull requests and weekly, so this does not quietly regress again.

One part of your report is not fixed and I do not want to leave you thinking it is: "when trying to print the file it always saves it to pdf ... and always the downloaded file is empty". Blank PDF output is #371 / #251, which is still open. I have just reproduced it and found the mechanism — the font index the converter uses (font_selection.bin) holds absolute paths to the font files, and when they do not resolve on the running machine x2t writes a PDF with no glyphs in it and still exits 0, so nothing is logged. That is a separate fix and I will follow up on #371.

Following up on the PDF half of your report, which I said I would: "when trying to print the file it always saves it to pdf ... and always the downloaded file is empty" is fixed for v0.4.0, by #402.

It was font_selection.bin shipping absolute paths to the bundled fonts as they were on the machine that built the package. When they did not resolve on the machine running, x2t wrote a PDF with no glyphs in it and exited 0, so nothing was logged anywhere. Paths are now pinned relative at build time, a font rebuild that does not rebuild fails loudly instead of reporting success, and x2t's stdout is scanned for Can't load fontfile so this cannot go quiet again.

Verified on the rig against master:

== a converted PDF has the text in it
   ok - "PdfFontProbe" is in the 12859 byte PDF
== a font path that does not resolve reaches the log
   ok - logged, and the PDF came out blank as expected
== a font rebuild that cannot write says so
   ok - exit 1, and it named the file
-- pdf: PASS in 6s

So both halves of what you reported — co-editing showing nothing, and blank PDF output — are fixed in v0.4.0.

Navigation Menu

Repository navigation

onlyoffice co editing #288

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

onlyoffice co editing #288

Description

Activity

gnosisd commented on Jan 14, 2023

life-on-mars commented on Feb 10, 2023

ChristophWolffNabu commented on Feb 21, 2023

gnosisd commented on Feb 21, 2023

fnyaker commented on May 6, 2023

Sicoval31 commented on May 16, 2023

zeptomoon commented on Jul 20, 2023

mattiscb commented on Aug 24, 2023

ServiceInfoHursin commented on Oct 3, 2023

roman-doubrava commented on Aug 29, 2024

Jerome-Herbinet commented on Oct 8, 2024

Jerome-Herbinet commented on Oct 8, 2024

kmille commented on Nov 21, 2024

chadek commented on Nov 21, 2024

chadek commented on Sep 4, 2026

yummiweb commented on Sep 11, 2026

chadek commented on Sep 14, 2026

chadek commented on Sep 14, 2026

chadek commented on Sep 15, 2026

chadek commented on Sep 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions