Created attachment 76815 [details]
When editing f file situated on shared samba resource (samba3-3.6.12-44.el5) and option "Always create backup copy" is set ON, save file fails with error message "Error saving the document xxx:
Error creating object.
Could not create backup copy"
LibreOffice Version 18.104.22.168 (Build ID: 5b93205). Free space on the disk is more then 3GB. Files mode is 666.
Backup dir ~/.config/libreoffice/3/user/backup is present.
When editing local files there is no such error.
How do you access the files on the shared samba resource, via a "traditional" mount into your local file system hierarchy, or via something like GVFS?
I mount share with smb4k to ~/smb4k/server/share.
Before I mounted shares with mount.cifs.
Result is the same.
Samba installed on server Scientific Linux release 5.8
LibreOffice on Fedora 16 and on Scientific Linux release 6.2
I'm getting the same error. I'm auto-mounting the network share with fstab. The error does not occur with files on the local drive. I have tried numerous fstab settings and always get the same error. I've tried mounting as smbfs and cifs with the same error resulting. The error does not occur when saving a file in the open format, but MS formats result in this error. File Save As and giving a new name functions fine. I can then do File Save As and select the original name, select to overwrite, and it saves the file.
Now I'm getting a similar, but slightly different error when saving to the native, open file format. It occurred when using writer. I get the same error, but if I hit save a second time, it completes the save function just fine. Apparently, the error occurs with every other save when saving to the open document format.
Any ideas on this one?
I have a slightly different observation:
here it works whenever I store to another filename. So with file1 and file2, I can always store an open file1 to file2, and when file2 is open, I can store to file1. The .bak is created, but empty. It seems the code tries .bak first, and then the 'real' location. It fails with .bak, and subsequently fails saving.
I would very much desire it did the other way round, at least! Or, if it failed with the .bak, it continued with the 'real' storage.
I wonder why status is UNCONFIRMED up to now. Bug is confirmed by Eugene (me), DOS286, Uwe Dippel. How many additional confirmations we need to change the bug status?
*** This bug has been marked as a duplicate of bug 55004 ***