Error while saving documents, bugs

[i716]

This very annoying error seems to be a bug in LO which has been around for about a year now.
When opening a file from a SMB share on a FBSD server, the file opens correctly but after editing and trying to save that file, it gives me first the following warning:

"Document file 'New Microsoft Excel Worksheet.xlsx' is locked for editing by:
Unknown User
Open document read-only or open a copy of the document for editing.
Select Notify to open read-only and get notified when the document becomes editable."

Clicking on cancel will yield the following error:

Error saving the document New Microsoft Excel Worksheet:
Object not accessible.
The object cannot be accessed
due to insufficient user rights.

(This can be circumvented by dismissing the first warning and then trying to save a again and it will behave normally)

No need to try teaching me about user user rights/permissions on *nix systems since I have 30+ experience with those and I can verify that both the original file as well as the lock file is created by a user that has full rw access to that share. Besides that it is only LO that is behaving that way and this only since around a year. This is extremely annoying.

NB: This bug seems to be around for more than a decade!! I might have just started to experience it since about a year ago.
https://bugs.documentfoundation.org/show_bug.cgi?id=55004

Version: 7.3.4.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: en-US (en_US.UTF-8); UI: en-US
7.3.4-1
Calc: threaded

[RobertG]

@i716

NB: This bug seems to be around for more than a decade!! I might have just started to experience it since about a year ago.
https://bugs.documentfoundation.org/show_bug.cgi?id=55004

This bug has been set to NEEDINFO 2022-06-18. If you could give this info …

[i716]

I will try to update to the latest version (fresh) and see if it changes anything. Otherwise I will add this info to the bug tracker. Thanks for the info.

[i716]

EDIT: I have performed a few tests yesterday night.

1. The same error can be reproduced by the most recent version of LO (7.3.3) on NixOS.
2. The error does not occur if the SMB share is mounted via gvfs (regardless of the LO version or OS used)
3. Adding the nobrl option to the cifs mount in fstab will prevent most of the errors but it still gives the following warning when first saving a newly created file.

The file has been changed since it was opened for editing in LibreOffice. Saving your version of the document will overwrite changes made by others.

Do you want to save anyway?

While the nobrl option might be a workaround for those who prefer cifs over gvfs (be it for speed reasons or whatever), this is clearly a bug that only LO has - and it is having it for quite a long time now. I suggest the devs take a look at it before considering rather useless “features” like UI changes and the like.

[ve3oat]

@i716

open a copy of the document for editing

Have you tried what the first error message suggests?

Also, have you tried saving the document in native .ods format first (always recommended), and then saving that document in the foreign and proprietary .xlsx format?

[erAck]

@i716

this is clearly a bug that only LO has - and it is having it for quite a long time now. I suggest the devs take a look at it before considering rather useless “features” like UI changes and the like

If it’s clearly a bug then please report it as such. Complaining here won’t help much (or only sometimes).

[i716]

@ve3oat
I will try to reproduce the error over the weekend if I find the time to do so.
But I I don’t see any reason why I would have to open a copy since I was the only person in the test environment that was working on this file. I can also confirm that it does not make any difference in which format the file is stored; I have performed numerous tests with newly created files both in MS format and .ods format which all result in the same error.
It seems that there are currently two somewhat acceptable solutions:
Either mount the share via gvfs or use a more traditional cifs mount with the nobrl option added to it. It will prevent either all or most of the errors as described above.

@erAck I generally would agree. But this bug has been reported numerous times -apparently since more than a decade ago- and there is no real progress. There is currently a ticket open on bugzilla which addresses this issue: https://bugs.documentfoundation.org/show_bug.cgi?id=55004