OnlyOffice file not saved, file changes lost upon exit

So, I was writing this document for one of my exams (homeschooling due to the current situation), and was working on it for 8 hours, where I started about 16:40 on the 27.03.2020 (if that helps searching in the log), until about midnight (00:01 28.03.2020). After finishing the task, I exited the editor (through the web interface), and forwarded the shared link to my teachers so they can read/download it.
I noticed my file size was suspiciously small, so I opened it to check, and noticed that 8 hours of work was gone. I've now spent over 2 hours troubleshooting and trying to rescue the file (even looked up the browser cache, but no success), and have at this point given up.

Below are the issue report, but it would save my day if someone knows a way to restore the file. I checked the versions history, but the only entry is even older, and it's not up to date either.

It should be noted, I was editing externally over the internet, so I don't know if something timed out on the server/client side, but here to hoping it can be restored, or at least resolved if this is not a config issue.

Steps to reproduce

1: Open and edit a word document created with OnlyOffice, as you normally would through the web interface.
2: Make constant changes to said document for a long time (I was writing for 8 hours straight)
3: Make sure the save icon is grey, and exit the document editor.
4: If the last "file update" time is not recent, re-open the document.
5: You may or may not encounter a warning screen mentioning OnlyOffice was not able to open the file properly, and the user is urged to download the file locally to their computer to be safe.
6: You do that, only to notice all the work since the reported "last update" time, is gone.
7: Rip your hairs out in frustration.

Expected behaviour

The document should be saved, and the file should be accessible as normal.

Actual behaviour

The file changes since last reported file update time are lost. OnlyOffice shows a warning about having issues opening the file properly, and downloading the file locally confirms that the changes since the reported file update time, are indeed lost into the void.

Server configuration detail

Operating system: Linux 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64

Webserver: Apache/2.4.29 (Ubuntu) (apache2handler)

Database: mysql 5.7.29

PHP version:

7.2.24-0ubuntu0.18.04.3
Modules loaded: Core, date, libxml, openssl, pcre, zlib, filter, hash, Reflection, SPL, sodium, session, standard, apache2handler, mysqlnd, PDO, xml, calendar, ctype, curl, dom, mbstring, fileinfo, ftp, gd, gettext, gmp, iconv, igbinary, imagick, intl, json, exif, mysqli, pdo_mysql, Phar, posix, readline, redis, shmop, SimpleXML, sockets, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xmlreader, xmlwriter, xsl, zip, Zend OPcache

Nextcloud version: 18.0.3 - 18.0.3.0

Updated from an older Nextcloud/ownCloud or fresh install: Updated from 18.0.1 a few weeks ago

Where did you install Nextcloud from: Unknown

Signing status

Array
(
)

List of activated apps

Enabled:
 - accessibility: 1.4.0
 - admin_audit: 1.8.0
 - analytics: 2.1.1
 - announcementcenter: 3.7.0
 - appointments: 1.1.10
 - apporder: 0.9.0
 - bookmarks: 2.3.4
 - browser_warning: 0.2.0
 - bruteforcesettings: 1.5.0
 - calendar: 2.0.2
 - camerarawpreviews: 0.7.3
 - cloud_federation_api: 1.1.0
 - cms_pico: 1.0.5
 - comments: 1.8.0
 - contacts: 3.2.0
 - cookbook: 0.6.1
 - dav: 1.14.0
 - deck: 0.8.0
 - documentserver_community: 0.1.5
 - external: 3.5.0
 - federatedfilesharing: 1.8.0
 - federation: 1.8.0
 - files: 1.13.1
 - files_accesscontrol: 1.8.1
 - files_automatedtagging: 1.8.2
 - files_external: 1.9.0
 - files_frommail: 0.4.0
 - files_linkeditor: 1.0.13
 - files_pdfviewer: 1.7.0
 - files_rightclick: 0.15.2
 - files_sharing: 1.10.1
 - files_trashbin: 1.8.0
 - files_versions: 1.11.0
 - files_videoplayer: 1.7.0
 - firstrunwizard: 2.7.0
 - forms: 1.1.1
 - group_everyone: 0.1.4
 - groupfolders: 6.0.3
 - groupquota: 0.1.2
 - impersonate: 1.5.0
 - issuetemplate: 0.6.0
 - logreader: 2.3.0
 - lookup_server_connector: 1.6.0
 - maps: 0.1.6
 - metadata: 0.11.1
 - music: 0.13.2
 - news: 14.1.3
 - nextcloud_announcements: 1.7.0
 - notes: 3.2.0
 - notifications: 2.6.0
 - oauth2: 1.6.0
 - occweb: 0.0.7
 - ocr: 6.0.25
 - onlyoffice: 4.1.4
 - passman: 2.3.5
 - password_policy: 1.8.0
 - photos: 1.0.0
 - previewgenerator: 2.2.0
 - privacy: 1.2.0
 - provisioning_api: 1.8.0
 - rainloop: 6.1.0
 - ransomware_protection: 1.6.1
 - recommendations: 0.6.0
 - serverinfo: 1.8.0
 - settings: 1.0.0
 - sharebymail: 1.8.0
 - sharingpath: 0.2.0
 - socialsharing_email: 2.0.0
 - socialsharing_facebook: 2.0.0
 - spreed: 8.0.5
 - support: 1.1.0
 - survey_client: 1.6.0
 - suspicious_login: 3.1.0
 - systemtags: 1.8.0
 - terms_of_service: 1.4.0
 - text: 2.0.0
 - theming: 1.9.0
 - theming_customcss: 1.5.0
 - twofactor_admin: 2.0.0
 - twofactor_backupcodes: 1.7.0
 - twofactor_nextcloud_notification: 2.2.0
 - updatenotification: 1.8.0
 - video_converter: 0.1.3
 - viewer: 1.2.0
 - workflow_pdf_converter: 1.3.1
 - workflow_script: 1.3.1
 - workflowengine: 2.0.0
Disabled:
 - activity
 - breezedark
 - carnet
 - cospend
 - encryption
 - files_external_gdrive
 - files_snapshots
 - flowupload
 - fulltextsearch
 - mail
 - ocdownloader
 - ocsms
 - openhab
 - phonetrack
 - ransomware_detection
 - registration
 - sensorlogger
 - unsplash
 - user_ldap

Configuration (config/config.php)

{
    "instanceid": "***REMOVED SENSITIVE VALUE***",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": [
       ***REMOVED SENSITIVE VALUE***
    ],
    "datadirectory": "***REMOVED SENSITIVE VALUE***",
    "dbtype": "mysql",
    "version": "18.0.3.0",
    "overwritehost": "***REMOVED SENSITIVE VALUE***",
    "dbname": "***REMOVED SENSITIVE VALUE***",
    "dbhost": "***REMOVED SENSITIVE VALUE***",
    "dbport": "",
    "dbtableprefix": "oc_",
    "mysql.utf8mb4": true,
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "installed": true,
    "memcache.locking": "\\OC\\Memcache\\Redis",
    "memcache.distributed": "\\OC\\Memcache\\Redis",
    "memcache.local": "\\OC\\Memcache\\Redis",
    "redis": {
        "host": "***REMOVED SENSITIVE VALUE***",
        "port": 6379,
        "timeout": 3
    },
    "maintenance": false,
    "mail_smtpmode": "smtp",
    "mail_sendmailmode": "smtp",
    "mail_from_address": "***REMOVED SENSITIVE VALUE***",
    "mail_domain": "***REMOVED SENSITIVE VALUE***",
    "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpport": "587",
    "mail_smtpsecure": "tls",
    "mail_smtpauthtype": "PLAIN",
    "mail_smtpauth": 1,
    "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
    "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
    "has_rebuilt_cache": true,
    "0": [
        "files_external_gdrive",
        "sharingpath",
        "files_frommail"
    ],
    "updater.release.channel": "stable",
    "theme": "",
    "loglevel": 2,
    "overwrite.cli.url": "***REMOVED SENSITIVE VALUE***"
}

Are you using external storage, if yes which one: local/smb/sftp/...

Are you using encryption:

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

Client configuration

Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36

Operating system: Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-91-generic x86_64)

Logs

Web server error log

[Fri Mar 27 06:25:07.033996 2020] [http2:warn] [pid 1677] AH10034: The mpm module (prefork.c) is not supported by mod_http2. The mpm determines how things are processe$
[Fri Mar 27 06:25:07.103638 2020] [mpm_prefork:notice] [pid 1677] AH00163: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 configured -- resuming normal operations
[Fri Mar 27 06:25:07.112819 2020] [core:notice] [pid 1677] AH00094: Command line: '/usr/sbin/apache2'
[Fri Mar 27 07:26:20.485392 2020] [php7:error] [pid 2513] [client 134.122.115.229:37018] script '/var/www/nextcloud/api.php' not found or unable to stat
[Fri Mar 27 07:26:21.464988 2020] [php7:error] [pid 4083] [client 134.122.115.229:37360] script '/var/www/nextcloud/login.php' not found or unable to stat
[Fri Mar 27 07:26:22.455490 2020] [php7:error] [pid 2513] [client 134.122.115.229:37714] script '/var/www/nextcloud/system_api.php' not found or unable to stat

Nextcloud log

https://easyupload.io/vw96h0
Password: nextcloudlogfile1

Browser log

Insert your browser log here, this could for example include:

Will include if necessary

I guess it's a duplicate of #12

I guess it's a duplicate of #12

#12 only has issues with file changes not being reflected by NextCloud, while my issue is the changes aren't saved to the document; downloading the file does not show the changes.

This is dreadful!!! I stopped using this extension because I also experienced issues like yours. Thankfully I've learned to mistrust new Nextcloud features. They're always half-baked and never production ready. This is yet another example.

Have you trying opening the file with the desktop onlyOffice app? OnlyOffice has its own server (the extension is just a bridge between the two), and I noticed that even though the document doesn't get udpated in Nextcloud, changes are saved in OnlyOffice server.

I also tried syncing the file using the normal sync, but if you open that file it will get corrupted. Only open from OnlyOffice app.

Yeah, I'll definitely be more sceptical towards stuff like this, especially "mission critical" features such as the OnlyOffice community app.

One of the first things I tried was actually to open it with the desktop version of OnlyOffice (which I've used in the past with no issues other than the wide spread user ghosting issue, although this occur in the web interface editor as well.

I haven't tried opening the file through the sync client, mainly due to a lot of users reporting corrupted files afterward.

I also host a lot of business and family files on the box, so I've disabled user access to OnlyOffice, but I'd like to open this again since having a private editing platform is a great relief in effort (changing locations and devices)

F*** i lost 7 pages of document writed yesterday !
I open the document today and i have a blank page !

Rip your hairs out in frustration.

YES !

@icewind1991

This is horrible. I don't see anything int he logs that could explain this, so I'm 100% unsure what caused it... But sorry to hear that you lost all your work this way, that really should never happen. @icewind1991 any clue what could cause this and how to debug?

any clue what could cause this and how to debug?

I'm not 100% sure, but it appears this issue is connected to #100

I was having some other "symptoms" as well though, such as:

User ghosting (your own user locks you out randomly from making changes to certain parts of the document for some amount of time.)
Some of my users were complaining about random (?) letters not showing when re-opening a document. As in the letters seem to be replaced by a space.
Especially tables were a nightmare to use, getting locked out for up to 5 minutes at a time, every 5 minutes.

I have the user ghosting too, when i'm re-opening document after minutes, some part of writer or calc document show red cells of myself using the document from the past, I wait 1 or 2 minutes and after disapearing, I can edit theses parts, but this is not a really a deep problem like loosing all the document ! (and concerns another issue I think)

I've found that Onlyoffice server and client promoted together inside from Nextcloud v18 makes 2 or 3 hours to push modifications to nextcloud system.
And unfortunatly, it happens that no modifications are recorded to nextcloud, period.

This problem didn't exist when I was using nextcloud with onlyoffice add-on and an external onlyoffice server.

I got paranoid, and I'm starting to get into the routine of downloading the ODS version before I close the Onlyoffice editor for fear that my changes won't make it down to the nextcloud.

Tx !

I can confirm this. Installed Nextcloud and OnlyOffice using Snap on an Ubuntu server. With several (smallish) spreadsheets changes are lost between closing and opening a file. This is when I edit directlyon the server using OnlyOffice in a browser and opening from the Files section of Nextcloud.

Additional info:

Downloading the file before closing has all the changes in it.
Saving file with a different name keeps the changes in the new file.

I have this issue too, and there's nothing in the logs that suggests a source for the error. Wow.

I had experienced something similar, but in my case the document updated on nextcloud's side after some time edits were made. I think caching might be to blame. Try to turn it off and see. And yeah, I didn't close the tab after exiting onlyoffice.
Other options: disable fast collaborative mode / autosave (I think I tried it and it didn't work, but I don't really remember) OR "save as", which is uncomfortable but might work.

In my case, both disabling fast collaborative editing and performing manual saves had no effect on committing changes to the remote document.

I ended up deploying a document server on a separate VPS, which seems to have solved this for me. In any case the reliability of data loss is a real problem for this project, especially given that it is easily installed through the nextcloud app ecosystem and advertised as a credible alternative to Google Docs.

Update: This is still an issue even with the separate Document Server. 🙃

#12 (comment)

I had a similar problem with nexctloud and the integrated community server - all files where empty when opened in external program like libre office!
However it worked when opening in the browser - but after an update of nextcloud the integrated community server stopped working (missing shared graphics lib on shared hosting). So now I have no access to these docs anymore.

Unfortunately some of the docs contained quite some work - so I setup up the community server on docker and got it to work finally. For new docs everything works fine.

Is there a chance that there is the content somewhere inside the community_server files?

Is the content of the docs only stored as the exported docx etc? How is it possible that we could still work with the docs -even the docx was empty?

Where are the docs persisted?

Any ideas?

@magicmatt007

@magicmatt007 and @alexrojo77

I just discovered the same issue today- I am new to OnlyOffice and noticed it appears to (but does not actually) save to some mounted filesystems (for me, Google Drive mounted through GNOME or through rclone). I also replicated it with a Samba share mounted through rclone. However, it worked normally when mounting the Samba share with the CIFS driver in /etc/stab.

The common denominator is that it fails to save actual changes to files mounted on a FUSE mounted directory, which is what GNOME and rclone and others use for mounting cloud drives.

This is fundamentally different than the original issue on this thread so I'll look to make a bug report elsewhere. I mainly wanted to get the word out that if you mount with a different drivers or use a bidirectional sync to a local drive, it will circumvent the bug.

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.

Ping. Severe data loss bugs should never be closed. Irresponsible.

…

On October 7, 2024 10:57:53 AM GMT+10:00, "github-actions[bot]" ***@***.***> wrote: 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. -- Reply to this email directly or view it on GitHub: #103 (comment) You are receiving this because you commented. Message ID: ***@***.***>

Same issue today : lost 10 hours of work.

Why dont you store version history offline???

When i drag'n'drop image inside my presentation my document tab just freezes.
I close, it asks if i want to save the document i say yes, then i open document again and it restored

Now I pressed "yes" on save prompt, reentered application, tried to paste image again, it got frozen again, i pressed "no" in save prompt because i just pressed "yes" a minute ago, I reenter the app and I see ONE HOUR OLD VERSION. And now when I search if there any saved version I see nothing thanks alot 👍👍👍👍

It will help me alot if you say "sorry to hear that" but can you actually do something to prevent it from happening again
?? Why does this problem exist since 2020???

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.

The only way a data loss bug should be closed is if it is fixedz or if the project is decommissioned.

…

On 1 December 2025 00:59:15 CET, "github-actions[bot]" ***@***.***> wrote: github-actions[bot] left a comment (nextcloud/documentserver_community#103) 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. -- Reply to this email directly or view it on GitHub: #103 (comment) You are receiving this because you commented. Message ID: ***@***.***>

Since my original issue, I've since moved over to a dedicated OO installation as the backend, and I only have similar issues when I have shoddy connectivity and high traffic/multiple tabs open (sometimes tabs gets left open when I move around and switch devices), but is otherwise fine.
AFAIK the devs have explicitly stated that they're aware of these issues; changes written to cache and/or DB, but never to the actual file due to misbehaving triggers.

That being said, an issue is an issue, and I agree that this should not be closed until it's resolved or decommissioned.

My advice to anyone with this issue: go through the trouble of spinning up an OnlyOffice image and use it as your backend. DO NOT rely on this app for anything other than simple notes or document viewing.

Fixed for v0.4.0, by #396 — far too late to be of any use to you, and I am sorry about the eight hours. The specific thing that happened to you, closing the editor and finding the file unchanged, is the case that is now handled directly.

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.

Ah yes, an LLM slopfix. Exactly what this needs.

Navigation Menu

Repository navigation

OnlyOffice file not saved, file changes lost upon exit #103

Steps to reproduce

Expected behaviour

Actual behaviour

Server configuration detail

Client configuration

Logs

8 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

OnlyOffice file not saved, file changes lost upon exit #103

Description

Steps to reproduce

Expected behaviour

Actual behaviour

Server configuration detail

Client configuration

Logs

Activity

biva commented on Apr 2, 2020

FreemoX commented on Apr 2, 2020

cortopy commented on Apr 2, 2020

FreemoX commented on Apr 2, 2020

ogmkp commented on Apr 10, 2020

jospoortvliet commented on Apr 14, 2020

FreemoX commented on Apr 14, 2020

ogmkp commented on Apr 14, 2020

leadermontanus commented on Jun 11, 2020

shibco commented on Jul 22, 2020

zamgreg commented on Jul 30, 2020

shibco commented on Jul 30, 2020

shibco commented on Aug 5, 2020

ogmkp commented on Aug 5, 2020

datacosmos commented on Oct 20, 2020

8 remaining items

tanjera commented on Apr 29, 2024

github-actions commented on Oct 7, 2024

shibco commented on Oct 8, 2024

pdeperth commented on Mar 14, 2025

goodhumored commented on Jun 19, 2025

github-actions commented on Nov 30, 2025

shibco commented on Dec 1, 2025

FreemoX commented on Dec 1, 2025

chadek commented on Sep 15, 2026

shibco commented on Sep 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions