OnlyOffice files not saving and file changes lost upon exit (synology NAS)

alexrojo77 commented 7 months ago

This issue is unique.

[X] I have used the search tool and did not find an issue describing my bug.

Operating System

Linux (DEB package)

Version information

7.5.1.23

Expected Behavior

Opened docx and xlsx files stored on network NAS (Synology; DSM7.2) via Nautilus file browser on Ubuntu 22.04. Made some changes then saved/closed file. Of course, I expected my changes to be saved upon exit and upon re-opening files but when I reopened the files the changes I had made were not there. Repeated this and observed same thing (ie changes were not saved). This is the first time I've observed this happening and was definitely working on a previous version of OnlyOffice.

Actual Behavior

Changes to docx and xlsx files are not being saved on exit. There was no indication of any errors when saving the file or exiting the program. OnlyOffice actually showed briefly in the window that it was saving the file. On the Nautilus file browser, I could also see that the files had not been modified based on the date/time.

Reproduction Steps

Open Nautilus file browser on Ubuntu Linux.
Open mapped network drive to document location on Synology (location mapped via SMB or DAVS share).
Double click on document or spreadsheet file.
Make changes as necessary.
Save file (either through save icon or menu or ctrl-s).
Close program.
Re-Open file. [file contents unchanged]

Additional information

I opened the same files using LibreOffice and the changes were properly saved. Seems like the issue is with OnlyOffice so I uninstalled this version of OnlyOffice and installed a previous release of OnlyOffice from GitHub (7.5.0). I was able to open the same files, make changes and save them properly.

cezarq commented 7 months ago

Same issue here running Ubuntu and OnlyOffice version 7.5.1.23 (snap)

dernippel commented 6 months ago

I can confirm this issue using Linux Mint 21.2 and the Flatpak package version 7.5.1.

kabe-inc commented 6 months ago

Same here, with both the latest .deb and flatpak versions.

Saving changes to a .docx or .xlsx file works if saving to a local folder, but the changes are lost if I save directly to my OneDrive cloud folder. This had previously been working fine, but seems to be broken in recent releases.

doryiii commented 4 months ago

Can confirm this is reproducible consistenly on 8.0.1:

Mount a network drive using GVFS with Nautilus (e.g. "sftp://some-server")
Open an existing .docx file or .xlsx file with Onlyoffice
Made some changes
Ctrl-S to save. Save toast notification popped up saying "saving document" and went away, just like normal saving.
Close Onlyoffice editor.
Reopen the file
Observe old content instead of new content after changes.

Note:

7.5.0 has the same issue. I am on Gnome 45.4 on Arch.
7.4.1 does not have the issue.

pingej77 commented 2 months ago

Same issue on Fedora 39. OnlyOffice 8.9.1.31 (flatpak), using OneDrive Fuse drive - file appears to save, but does not save. Saving a copy locally and using cp or rsync seems to work as a workaround.

I'm not sure if's helpful, but I found this https://www.onlyoffice.com/blog/2020/04/save-and-force-save-in-onlyoffice-never-lose-a-document which seemed promising as a workaround, but it appears to be for an older version of OnlyOffice -- I cannot find those "common settings" anywhere in my version and the saving settings under "advanced settings" no longer have that option.

XDmitryK commented 2 months ago

@pingej77 Hi In your case I think the problem is related to issue #1503

DUB1401 commented 2 months ago

I also have this problem on Fedora Silverblue 40.

OnlyOffice 8.0.1 (Flatpak)

tanjera commented 2 months ago

I've discovered/reproduced this in 8.0.1 on a few Linux installations. I did some testing to help diagnose the problem @XDmitryK and it only happens for me on a FUSE mount, mounting either Google Drive or a Samba share through the desktop environment (Nautilus or Thunar) or through an rclone mount. However, when I mount the same Samba share using cifs-util and mount.cifs in /etc/fstab, no problem!

I will be circumventing the problem by writing changes to the local drive and using a bidirectional file sync to push changes to the cloud drive.

tanjera commented 2 months ago

I've discovered/reproduced this in 8.0.1 on a few Linux installations. I did some testing to help diagnose the problem @XDmitryK and it only happens for me on a FUSE mount

While this issue existed for me with FUSE mounts made with different programs (Nautilus and rclone), I've found documentation that it is a known limitation of the vfs-cache documented at https://rclone.org/commands/rclone_mount/ under "Limitations", specifically:

Without the use of --vfs-cache-mode this can only write files sequentially, it can only seek when reading. This means that many applications won't work with their files on an rclone mount without --vfs-cache-mode writes or --vfs-cache-mode full. See the VFS File Caching section for more info. When using NFS mount on macOS, if you don't specify |--vfs-cache-mode| the mount point will be read-only.

Relevant to this, Nautilus uses its own implementation of gvfs https://wiki.gnome.org/Projects/gvfs ... not sure what its limitations are (?).

Mounting Google Drive via rclone w/ --vfs-cache-mode=full I tested and was successfully saving files directly to the FUSE drive with all programs working as expected. The file changes propagated successfully across to Google Drive and were readable in a browser on a different machine (so not read from cache!) Since the issue with saving looks like a problem with file caching on FUSE and the layers used to mount/access it... unless it has to do with the way OnlyOffice is accessing the filesystem (doubtful), I think the only thing in the scope for OnlyOffice, especially since it is cross-platform and used in so many environments:

Ensure that file saves are actually saved; (e.g. check actual filesystem output for parity with intended filestream output perhaps cached in memory? ... or check file timestamp for DateTime::Now() to ensure file is updated ... or is there an error being returned from the FUSE filesystem that isn't being received/handled by OnlyOffice?)
Warn the user if the save was not successful (e.g. "It appears the saved file was not written to the hard drive; Please ")

In the meantime, @pingej77 @doryiii @kabe-inc (OS?) @dernippel and the people posting in #1503 may want to check if their filesystem mount has known caching limitations. Perhaps worth trying rclone w/ the vfs-cache-mode=writes flag

kabe-inc commented 2 months ago

@tanjera nice work! In response to your question, I'm using EndeavourOS + Gnome + Nautilus + Onedriver to handle the filesystem mount.

alexrojo77 commented 2 months ago

@tanjera I wouldn't consider myself an expert at linux so not sure how to apply some of the mounting options you mention. If you can can provide some instructions, I might be able to figure out how to do it, test it and report back.

As for the the caching limitations, somehow I don't think this is it even though I'm hardly an expert. As mentioned in my original issue, I was able to manually install an older version (7.5.0.127) and was able to open and save files without any problems. This is all using the same file browser and not making any changes to how the file server is mounted. I also just installed the latest flatpak version (8.0.1.31) alongside the old version and I only experience the not saving issue with the newer version. The mounting and way I access the file all being the same. As doryiii said, a notification window does come up saying it is saving the document but when the file is re-opened, the new changes aren't there and the date/time stamp isn't updated either suggesting the file hasn't been saved.

tanjera commented 2 months ago

@alexrojo77 I agree with you- you've definitely seen a change in behavior between versions of OnlyOffice and ensuring that the program behaves as is best for the operating system might be room for this program to better itself. One of the reasons caching is needed (at least with VFS/rclone per the docs) are that if a file is being read and written to simultaneously, it will fail... I suspect handling the memory->file streams may be what changed in the versions. I tried to sift through the OnlyOffice code but couldn't find the save routine.

As far as mounting with a write cache enabled, here are the steps I used:

Install rclone (your comment from November said you were on Debian- sudo apt install rclone
Setup rclone using rclone config (does not need to be run as sudo/root)
- Go through the steps of setting up a cloud drive and authenticating
Mount the drive (you do need write access to the mounting folder!) using rclone mount --vfs-cache-mode=writes --daemon clouddrivename: /mount/directory/here

For example, the line in my crontab is @reboot rclone mount --vfs-cache-mode=writes --daemon gdrive: "/mnt/Google Drive/" as I named my cloud drive "gdrive" in rclone config

I've used OnlyOffice a bunch over the last few days without a single problem since setting the cache mode.

XDmitryK commented 2 months ago

@alexrojo77 I can confirm - this is bug, so I have created issue #67855. @tanjera Thanks for your feedback. I think Google Drive is not working due to an issue #1442. We are in the process of solving this problem

ONLYOFFICE / DesktopEditors