https://bugs.documentfoundation.org/show_bug.cgi?id=93117
Bug ID: 93117
Summary: LibreOffice freezes when trying to
access/open/read/write documents on NFS mounts
Product: LibreOffice
Version: 4.3.3.2 release
Hardware: Other
OS: Linux (All)
Status: UNCONFIRMED
Severity: critical
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
LibreOffice is unable to access files on NFS mounts (at least NFSv3).
When trying to open a remote (odt) file, the splash screen freezes. The process
has to be killed (SIGKILL). Opening a file in read-only mode appears to work.
Same thing when trying to save a file on an NFS mount. The window freezes, it's
not even possible to select and copy the text to the clipboard, it's gone. I
lost a document because I forgot to copy everything to the clipboard before
saving - in case LibreOffice crashes.
Interestingly, the file was created (but it's empty), along with a LibreOffice
lock file (".~lock...").
This basically makes LibreOffice impossible to work with, on a central NFS
storage, at least by default. Given that a central storage for all data is a
very common setup, this is a significant bug. When trying to save, this can
even cause data loss. The safe workaround is copying the file to the local
system, edit it locally and then move it back to the storage.
Using the default LibreOffice from the Arch repository:
LibreOffice 4.3.3.2 430m0(Build:2)
NFSv3 is used (hard - nolock option is *not* used)
It's frustrating that some people seem to suggest using the nolock mount
option, or even worse, migrating everything to NFSv4. Besides certain issues
like NFSv4 sometimes having issues when NFSv3 works perfectly fine, it's not a
proper solution to migrate NFS because of LibreOffice.
The Arch documentation recommends modifying the LibreOffice wrapper script
/usr/lib/libreoffice/program/soffice:
https://wiki.archlinux.org/index.php/LibreOffice#Hanging_when_using_NFSv3_shares
However, none of this is limited to one distribution (like Arch) and no regular
person will/should edit a shell script in order to make LibreOffice work. (And
what happens when updating, the script might be replaced.)
Again, telling an end user to hack in shell scripts has nothing to do with a
solution. If the locking feature isn't working by default, maybe it should be
disabled by default?
I have found similar bugs regarding this issue, but no actual solution so far.
For example, there is an old OpenOffice bug which was closed (without solution)
because "Go_oo does not exist anymore". There are similar LibreOffice bugs, but
there are differences, some describe a problem when opening only but not when
saving, others describe error messages (there's no error message here).
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
