Edits and changes made in Onlyoffice are not synced into Nextcloud

[timo12357]

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

1. Use a desktop wordprocessor and create a document in a NextCloud synced folder in your desktop environment
2. Log onto the Nextcloud web UI and open the file with OnlyOffice.
3. Ask colleague to do the same
4. Make changes in document
5. Exit document
6. Open document with desktop wordprocessor from local NextCloud synced folder.
7. Notice that the changes never were saved to the file in NextCloud,.
8. Open file in OnlyOffice from the Nextcloud web UI to notice changes are still there
9. Close OnlyOffice
10. Make minimal change in the desktop wordprocessor and save file locally.
11. Let NextCloud sync
12. 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
13. 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

[Ulch]

I can confirm this behavior in an environment with Nextcloud 18.0.3, OnlyOffice Community Server bundled with NextCloud 18 and Nextcloud desktop client 2.5.1git on Debian 10.

A fix would be highly desirable to allow the deployment of Nextcloud Hub in productive environments.

[timo12357]

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.

[timo12357]

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.

[fabiangebert]

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?

[timo12357]

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

[skjnldsv]

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

[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.

[fabiangebert]

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

[timo12357]

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

[p-jo]

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

[timo12357]

Mine are NOT saving on normal cron run.

[timo12357]

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.

[fabiangebert]

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?

[timo12357]

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

[fabiangebert]

When setting Cron to AJAX it works. So it seems, either my hoster has messed up the cron Configuration or cron doesn't use the correct user name? There should be an indication in the OnlyOffice community server settings about the last time the cron ran successfully.

[skjnldsv]

There should be an indication in the OnlyOffice community server settings about the last time the cron ran successfully.

There is in your cron setup page

[fabiangebert]

There should be an indication in the OnlyOffice community server settings about the last time the cron ran successfully.

There is in your cron setup page

I know, but it will show up regardless if the Community Server was able to write the files. But it could be that I am missing the logs. I'll reach out to my hoster now.

[flow10]

Can confirm this issue. Changing the cron settings does not resolve this for me.
Unfortunately this makes OO community server unusable.

[icewind1991]

To clarify, the "intended behaviour" is that documents are saved when the cron runs after all users close the document.

If your documents are not saving properly even some time after closing, please verify that your cron is functional (see skjnldsv's comment above) and check your nextcloud log for any errors that might have been thrown during saving.

[FreemoX]

I'm experiencing the same issues ( #103 ) as mention by OP, although without anyone else editing my file at the same time (someone was working with me on a paper, but they started working after I exited the editor and saved my file). I don't have issues with cron not working (as far as I know), so I don't know if mine and OPs issues are the same, but it seems to be an issue with the newer NextCloud versions. Seems to me that the editor either times out or gets "confused" as soon as another person edits the same file, or there is a writing issue from the cache.

[timo12357]

Our cron is functional. Nevertheless, the changes are lost.
This is worth to be tagged a bug.

[HFranz]

Our cron is functional. Nevertheless, the changes are lost.
This is worth to be tagged a bug.

Same here. I had this behavior, but I can not reproduce anymore. I’m using system cron on an own server.

[Ulch]

Since I also haven't been able to solve the issue by adjusting the cron settings I contacted my hoster and asked him to address the problem. His response:

At the moment I don't have a solution for you and can only ask you to be patient until a new version with a correction of this error is being published.

I really think it would be great if this could be tagged as a bug and get the attention of the developers. As others in this thread also said, this is a serious problem which makes OO community server unusable and in part jeopardizes the whole idea of Nextcloud "Hub".

[lefpiz]

Same problem here. It seems to be a problem of writing data from the database back to the files nextcloud. I have the following warning in the /var/log/nextcloud.log all the time. Do you have the same errors in the logfile?

{"reqId":"1RFumGuNoErgHMyNyJqi","level":3,"time":"2020-04-01T09:00:22+02:00","remoteAddr":"","user":"--","app":"documentserver_community","method":"","url":"--","message":{"Exception":"OCA\DocumentServer\Document\DocumentConversionException","Message":"namespace error : Namespace prefix wp14 on sizeRelH is not defined\nr 3" hidden="false"/>wp:cNvGraphicFramePr/<wp14:sizeRelH relativeFrom="margin"\n ^\nnamespace error : Namespace prefix wp14 on pctWidth is not defined\nlse"/>wp:cNvGraphicFramePr/<wp14:sizeRelH relativeFrom="margin"><wp14:pctWidth\n ^\nnamespace error : Namespace prefix wp14 on sizeRelV is not defined\n4:pctWidth>0</wp14:pctWidth></wp14:sizeRelH><wp14:sizeRelV relativeFrom="margin"\n ^\nnamespace error : Namespace prefix wp14 on pctHeight is not defined\n14:pctWidth></wp14:sizeRelH><wp14:sizeRelV relativeFrom="margin"><wp14:pctHeight\n ^\n","Code":0,"Trace":[{"file":"/var/www/nextcloud/apps/documentserver_community/lib/DocumentConverter.php","line":123,"function":"run","class":"OCA\DocumentServer\Document\ConverterBinary","type":"->","args":["/upload_tmp/oc_tmp_mqVjBS-.xml",null]},{"file":"/var/www/nextcloud/apps/documentserver_community/lib/DocumentConverter.php","line":78,"function":"runCommand","class":"OCA\DocumentServer\DocumentConverter","type":"->","args":[{"class":"OCA\DocumentServer\Document\ConvertCommand"}]},{"file":"/var/www/nextcloud/apps/documentserver_community/lib/Document/DocumentStore.php","line":151,"function":"saveChanges","class":"OCA\DocumentServer\DocumentConverter","type":"->","args":["*** sensitive parameter replaced ",["78;AgAAADEA//8BAEtMDRkkwgUAhwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA9v///xwAAAA1AC4ANAAuADIALgA0ADYALgBAAEAAUgBlAHYA","34;BgAAADYAMQAwAAIAHAABAAAABwAAAAIAAAAAAAAAAAAAAA=="],"/var/nc_data/appdata_ocrvn9u8e3bd/documentserver_community/doc_754877581/saved.docx","docx"]},{"file":"/var/www/nextcloud/apps/documentserver_community/lib/LocalAppData.php","line":100,"function":"OCA\DocumentServer\Document\{closure}","class":"OCA\DocumentServer\Document\DocumentStore","type":"->","args":[" sensitive parameters replaced ***"]},{"file":"/var/www/nextcloud/apps/documentserver_community/lib/Document/DocumentStore.php","line":164,"function":"getReadWriteLocalPath","class":"OCA\DocumentServer\LocalAppData","type":"->","args":[{"class":"OC\Files\SimpleFS\SimpleFolder"},{"class":"Closure"}]},{"file":"/var/www/nextcloud/apps/documentserver_community/lib/Document/SaveHandler.php","line":56,"function":"saveChanges","class":"OCA\DocumentServer\Document\DocumentStore","type":"->","args":[754877581,[{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"},{"class":"OCA\DocumentServer\Document\Change"}]]},{"file":"/var/www/nextcloud/apps/documentserver_community/lib/BackgroundJob/Cleanup.php","line":69,"function":"flushChanges","class":"OCA\DocumentServer\Document\SaveHandler","type":"->","args":[754877581]},{"file":"/var/www/nextcloud/lib/public/BackgroundJob/Job.php","line":79,"function":"run","class":"OCA\DocumentServer\BackgroundJob\Cleanup","type":"->","args":[null]},{"file":"/var/www/nextcloud/cron.php","line":125,"function":"execute","class":"OCP\BackgroundJob\Job","type":"->","args":[{"class":"OC\BackgroundJob\JobList"},{"class":"OC\Log"}]}],"File":"/var/www/nextcloud/apps/documentserver_community/lib/Document/ConverterBinary.php","Line":64,"CustomMessage":"Error while applying changes for document 754877581"},"userAgent":"--","version":"18.0.3.0"}

[biva]

Shouldn't we have a unique place to discuss this issue wich looks very important to a lot of people? The oldest one I found on the nextcloud repository is #12 and the main one on ONLYOFFICE repository is ONLYOFFICE/onlyoffice-nextcloud#21 (with a specific interesting comment in ONLYOFFICE/onlyoffice-nextcloud#21 (comment))

[timo12357]

Shouldn't we have a unique place to discuss this issue wich looks very important to a lot of people? The oldest one I found on the nextcloud repository is #12 and the main one on ONLYOFFICE repository is ONLYOFFICE/onlyoffice-nextcloud#21 (with a specific interesting comment in ONLYOFFICE/onlyoffice-nextcloud#21 (comment))

Yes it should, but not one of these reports on the issue has been tagged as a bug. Apparently it is not a bug?
We solved the problem by removing Onlyoffice from our Nextcloud Hub immediately when this, erm, "undocumented feature" was identified. No files have been lost since, and work continues.

[tjareson]

We solved the problem by removing Onlyoffice from our Nextcloud Hub immediately when this, erm, "undocumented feature" was identified. No files have been lost since, and work continues.

Same here. I've tried all kind of counter measures, also running
/usr/bin/docker exec -t containername sudo -u www-data php occ documentserver:flush
as cron job just produced "more sophisticated" data loss, like just the changes were left in the document but the rest was missing and things alike.

Our solution: use collabora as docker container. It is not as compatible with MS office docs as onlyoffice, but right now for us the only solution that works reliable with nextcloud.
Not saving changes destroys the trust in cloud based work environments and brings future discussions for me ("...it just wasn't saved, I don't know...") I can not argue with the users anymore.

It's sad that the magnitude of this issue for user trust into nextcloud is somehow not noticed/ignored.

[arnowelzel]

@petronem There is a setting in the Nextcloud integration app to force saving the document even if still people working on in:

[janpekar]

This issue is really bad and I was expecting it long time before it happened in our installation. One of Murphy's law - "Anything that can go wrong will go wrong." so any async write few minutes after last user will leave document is unstable/unreliable solution. It cost me loss of my reliability in front of my customer so price was high.
One way from this is (from my point of view) user notification, that something is wrong. I don't know how forcesave behave (if it will notify me that saving was not successful), but another way can be monitoring of folder App_Data/cache/files (see docker volumes) or /var/log/onlyoffice/documentserver/docservice/ logfiles.

I have found these errors in /var/log/ folder mentioned above and I will watch them by my automated system. Hope they will be always empty :) and I will never face this issue again

[2021-10-19T17:35:42.623] [WARN] nodeJS - sendServerRequest returned an error: docId = 2953693985; data = {"error":1}
[2021-10-19T17:35:42.726] [WARN] nodeJS - storeForgotten: docId = 2953693985
[2021-10-21T22:46:51.827] [WARN] nodeJS - sendServerRequest returned an error: docId = 2466466171; data = {"error":1}
[2021-10-21T22:46:51.854] [WARN] nodeJS - storeForgotten: docId = 2466466171
[2021-10-25T23:28:07.168] [WARN] nodeJS - sendServerRequest returned an error: docId = 3749137724; data = {"error":1}
[2021-10-25T23:28:07.260] [WARN] nodeJS - storeForgotten: docId = 3749137724
[2021-10-26T12:29:07.037] [WARN] nodeJS - sendServerRequest returned an error: docId = 2466466171; data = {"error":1}
[2021-10-26T12:29:07.113] [WARN] nodeJS - storeForgotten: docId = 2466466171
[2021-10-26T12:47:54.585] [WARN] nodeJS - sendServerRequest returned an error: docId = 2466466171; data = {"error":1}
[2021-10-26T12:47:54.624] [WARN] nodeJS - storeForgotten: docId = 2466466171
[2021-10-26T13:25:57.324] [WARN] nodeJS - sendServerRequest returned an error: docId = 3749137724; data = {"error":1}
[2021-10-26T13:25:57.385] [WARN] nodeJS - storeForgotten: docId = 3749137724
[2021-10-26T14:32:48.883] [WARN] nodeJS - sendServerRequest returned an error: docId = 2466466171; data = {"error":1}
[2021-10-26T14:32:48.919] [WARN] nodeJS - storeForgotten: docId = 2466466171
[2021-10-26T14:36:35.557] [WARN] nodeJS - sendServerRequest returned an error: docId = 2466466171; data = {"error":1}
[2021-10-26T14:36:35.586] [WARN] nodeJS - storeForgotten: docId = 2466466171
[2021-10-26T14:38:46.669] [WARN] nodeJS - sendServerRequest returned an error: docId = 3748264367; data = {"error":1}
[2021-10-26T14:38:46.709] [WARN] nodeJS - storeForgotten: docId = 3748264367

[janpekar]

I was not satisfied by forcesave option in nextcloud so I decided to utilize services.CoAuthoring.autoAssembly.interval see https://api.onlyoffice.com/editors/save#forcesave

It was not working as I expected (savings were at random interval not interval I expected) but it was better than nothing. It can be because I'm running nextcloud cron at random interval..

I'm using docker for documentserver so if you want to try, I created script which modifies image to utilize autoAssembly.interval. You can run it after onlyoffice image update.

I created gist for that see - https://gist.github.com/janpekar/0d506647f77aa2261ee10b0fd21337e3

[w202mg]

Having same issue here. After so long time still no solution... wow... I mean there could be lots of small bugs but this is something really terrible.
By the way I'm using a selfhosted server.

[phygman]

I've been having the same issue, even lost some data I wish I wouldn't have.

I think I have a fix. At least on my system. I'm running nextcloud on an ubuntu VM, and onlyoffice in a docker.
I found that by setting the onlyoffice co-editing mode to strict causes OO to save properly and nextcloud to then sync properly.

Open a document in onlyoffice
In the upper right of the editor, click on the 3 horizontal lines. Between the 'Mark as favorite' star and the avatar icon with your username.
select 'Advanced Settings'
Make sure you are on the 'General' page
change the 'Co-editing Mode' to 'Strict'
click 'Apply'

This seems to be working for me, with a couple on minutes of testing a scenario that always failed. But YMMV.

[biva]

My advice to everybody here: do not use the integrated version (Community Document Server), it's not stable enough in my experience. Make a proper OnlyOffice install, for example with Docker, and use the connector only. I did it and I never met issues anymore. YunoHost is also an easy alternative to avoid problems. (same advice is provided here: #12 (comment))

[mhl66]

Since two years, unsuspecting users are dragged into this trap - could anyone please remove this embarrassing crap from the Nextcloud App Store!?!

[ionics]

This is a disaster!!! User gets false secure feeling about having backed up data while in real life it is stored in cache and lost. As @mhl66 suggests: => This should be removed from the App Store immediately.

[ristein]

I'm using onlyoffice-server in docker since the document server app is not compatible with version 24.
Seems like the option "Keep intermediate versions when editing (forcesave)" under Settings->Administration->Onlyoffice is not doing anything.

[NotSoFunnyClown]

This bug results in data loss! Don't use it, if you don't want to use your office work.

[arnowelzel]

I already created a pull request a while ago to add a notice to the app that this is only a proof of concept and should not be used for production (#219). Unfortunately nobody seems to care :-(

Whoever is responsible for this - please remove that app or add at least a warning that it is not maintained any longer and should not be used! It does not help anyone! Nextcloud gets a bad reputation since an app does not work properly and OnlyOffice also gets a bad reputation.

And for users - use the docker version provided by Ascension and their connector for Nextcloud, this works fine.

[dubwoc]

This still seems to be relevant despite the linked bug above showing an up of the document server from November of 2022. I have already experienced data loss because of the exact problems described here and therefore cannot accept this as a solution for collaborative document editing. Has anyone found any better options on Nextcloud or elsewhere?

[arnowelzel]

This still seems to be relevant despite the linked bug above showing an up of the document server from November of 2022. I have already experienced data loss because of the exact problems described here and therefore cannot accept this as a solution for collaborative document editing. Has anyone found any better options on Nextcloud or elsewhere?

You can use the "official" OnlyOffice document server in Docker and the integration app by Ascensio which works much better. However with Nextcloud 25 you may have some issues as the new UI of NC 25 seems not to be supported fully yet and editing of shared documents for guests may also not work yet.

You may also give "Nextcloud Office" a try - that is based on Collabora (see https://www.collaboraoffice.com) which uses LibreOffice as backend and also works quite well. Nextcloud Office can either use a standalone backend server (Docker is also supported) or the integrated CODE server in Nextcloud.

Eventhough Nextcloud Office may look a bit "old fashioned" it works quite well for me.

[TeaDrinkingProgrammer]

How on earth is this still an issue? I have switched to a managed payed Nextcloud instance partially because I wanted to use OnlyOffice: Collabora is disables because of performance reasons. Because of this shitshow, I cannot use any document editing

[arnowelzel]

How on earth is this still an issue? I have switched to a managed payed Nextcloud instance partially because I wanted to use OnlyOffice: Collabora is disables because of performance reasons. Because of this shitshow, I cannot use any document editing

I have Nextcloud on my own server which costs around 30 EUR per month and provides enough space and power for 60 users including OnlyOffice or Nextcloud Office in a docker container. You should ask the provider of the managed Nextcloud instance, if they have a different plan which includes that. Even with smaller virtual servers for about 10-20 EUR per month using the Docker for OnlyOffice is not a big deal if you do not have dozens of users working all the the same time.

[TeaDrinkingProgrammer]

I have Nextcloud on my own server which costs around 30 EUR per month and provides enough space and power for 60 users including OnlyOffice or Nextcloud Office in a docker container. You should ask the provider of the managed Nextcloud instance, if they have a different plan which includes that. Even with smaller virtual servers for about 10-20 EUR per month using the Docker for OnlyOffice is not a big deal if you do not have dozens of users working all the the same time.

It's a Hetzner instance which we use as a household, so I am afraid that 30 EUR would a bit too expensive. Oh well, it was not my main use for it, but that doesn't make it less annoying

[arnowelzel]

Well - you can also just grab a Raspberry Pi with a case and SSD and use Nextcloud including OnlyOffice there.

[kintaro1981]

Same problem here. 👎
I'm on Storage Share from Hetzner

I really want to runaway from Google Drive but with this issue I can't trust Nextcloud. 😞

[chadek]

This PR might solve this issue. If someone can test this out, it would be appreciated

[kintaro1981]

I can't test it as I use a managed nextcloud. I hope some self hosted nextcloud users can test it out.

[kintaro1981]

I tried document server 0.1.16 and it "fixed" for me (NC managed by hetzner - storage share).

In my case modifications made in onlyoffice are synced back to nextcloud (windows) clients every 5 minutes, not perfect but better than nothing.

the only problem is that modified date/time of files in the client filesystem is not the same as in nextcloud server

[chadek]

I already had this kind of trouble using docker onlyoffice docker images with seafile in the past, I solved it it by enabling onlyoffice Auto assembly option which is not by default and as you figured it out, by default it saves the document every 5 minutes while it is open or when every connection to the document server for that document is closed (so if one get the document always open in a browser tab, it kind of never save if Auto assembly is disable).

As this PHP wrapper is all but easy to understand, I tried to activate the Auto assembly option without changing defaults value which are probably fine and ask for you guys for feed back to ensure it actually work.

I think this wrapper still miss some "features", trying onlyoffice webapp I guessed by the behavior of the app, settings are not taken into account (could not trigger the manual saving option).

So now I know that at least, I can effectively affect the document server behavior manipulating it's normal configuration file, I could adjusts parameters to fit the "normal" average usage of this app.

Parameters of the document server are available here. I can drop the 5 minutes forcesave option to 1 or 2 maybe if you feel 5 is to much.

[arnowelzel]

I never had any issues when using the Docker container provided at https://hub.docker.com/r/onlyoffice/documentserver.

The script I use to pull/update the container images:

#!/bin/sh

docker pull onlyoffice/documentserver
docker stop onlyoffice
docker rm onlyoffice
docker run -i -t -d --name="onlyoffice" -p 127.0.0.1:8085:80 --restart=always -e JWT_ENABLED="true" -e JWT_SECRET="mysecret" onlyoffice/documentserver

Of course use your own password instead of mysecret!

However, keep in mind that when using a reverse proxy you have to be careful to include websockets as well, like in my configuration for Apache (which uses a TLS certficate provided by Let's Encrypt, domain onlyoffice.example has to be replaced with the real domain you use for OnlyOffice of course):

<VirtualHost *:443>
        DocumentRoot /var/www/onlyoffice.example

        ServerName onlyoffice.example

        <Directory /var/www/onlyoffice.example>
                Options +SymlinksIfOwnerMatch
                AllowOverride All
                Require all granted
        </Directory>

        # OfficeOnly integration
        SetEnvIf Host "^(.*)$" THE_HOST=$1
        RequestHeader setifempty X-Forwarded-Proto https
        RequestHeader setifempty X-Forwarded-Host %{THE_HOST}e
        ProxyAddHeaders Off
        ProxyPass /.well-known !

        RewriteEngine On
        RewriteCond %{HTTP:Upgrade} websocket [NC]
        RewriteCond %{HTTP:Connection} upgrade [NC]
        RewriteRule ^/?(.*) "ws://127.0.0.1:8085/$1" [P,L]
        ProxyPass / http://127.0.0.1:8085/
        ProxyPassReverse / http://127.0.0.1:8085/

        ErrorLog ${APACHE_LOG_DIR}/onlyoffice.example-error.log
        CustomLog ${APACHE_LOG_DIR}/onlyoffice.example-access.log combined

        # Provide .well-known path for ACME challenge
        Include "/etc/apache2/conf-available/acme.conf"

        SSLCertificateFile /etc/letsencrypt/live/onlyoffice.example/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/onlyoffice.example/privkey.pem
        Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

[MaaartinK]

Hello,

I reported a problem with data loss / saving before here.

Unfortunately the issue is not solved, even though the new version 0.1.16 was supposed to eliminate this problem. - I just had another data loss after closing the doc (with work longer than 5 min as it was mentioned as the saving cycle). No idea what to do here.

Another issue I have (and I don't know if it is related):
When editing a doc sometimes (!), but quite often a red bracket appears in the row or wherever I edited (after I press return), warning me that "my own account is editing this section right now" and I can't edit this particular row or part. I have to wait (sometimes minutes, sometimes days), before magically being granted access again. This is quite annoying.

Any help is highly appreciated.