Hello Martin, *,
have you tried a newer version of LO than 3.6.0.4? Does your problem occurs there, too? I have no samba here to test, so this is only a little reminder ... ;)

If you error still occur:
1. Could you give us some more details like with distro on what archtecture are you using?
2. How do you connect your samba client to the server? And which samba version on the client and server are you using?
3. Which OS do you want to use via samba?
4. Would you be so kind to start LO from commandline to see, if there is any error message, please? And maybe with "soffice --backtrace" and attach the backtrace log to this bug?

Sorry for the inconvenience
Thomas.

(In reply to comment #1)
> Hello Martin, *,
> have you tried a newer version of LO than 3.6.0.4? Does your problem occurs
> there, too? I have no samba here to test, so this is only a little reminder
> ... ;)

Same error using Version 3.6.6.2 (Build ID: 3.6.6.2-9.fc18)

> 
> If you error still occur:
> 1. Could you give us some more details like with distro on what archtecture
> are you using?

Ubuntu when I reported the bug, fc18 now.

> 2. How do you connect your samba client to the server? And which samba
> version on the client and server are you using?

cifs mount (replaced some private parts with '*'):

//samba.*****.de/home on /samba type cifs (rw,nosuid,nodev,noexec,relatime,vers=1.0,sec=ntlmssp,cache=strict,unc=\\samba.***domain****\home,username=****,domain=****,uid=1000,forceuid,gid=0,noforcegid,addr=***IP***,file_mode=0644,dir_mode=0755,nounix,rsize=61440,wsize=65536,actimeo=1)

> 3. Which OS do you want to use via samba?
? Don't get it: client is Linux fc18, server is Red Hat Enterprise Linux Server release 6.1 (Santiago)
samba-3.5.6-86.el6_1.4.x86_64

> 4. Would you be so kind to start LO from commandline to see, if there is any
> error message, please? And maybe with "soffice --backtrace" and attach the
> backtrace log to this bug?

soffice --backtrace
GNU gdb (GDB) Fedora (7.5.1-38.fc18)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib64/libreoffice/program/soffice.bin...Reading symbols from /usr/lib/debug/usr/lib64/libreoffice/program/soffice.bin.debug...done.
done.
log will be saved as gdbtrace.log, this will take some time, patience...
(gdb) 

less gdbtrace.log 
warning: Currently logging to gdbtrace.log.  Turn the logging off and on to make the new setting effective.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: "/usr/lib/debug/usr/lib64/libicudata.so.49.1.1.debug": separate debug info file has no debug info
[New Thread 0x7ffff7fa3700 (LWP 6496)]
[New Thread 0x7fffedb44700 (LWP 6497)]
[New Thread 0x7fffed343700 (LWP 6498)]
[New Thread 0x7fffe6c56700 (LWP 6501)]
[New Thread 0x7fffe5ad9700 (LWP 6502)]
[New Thread 0x7fffe5217700 (LWP 6503)]
Detaching after fork from child process 6504.
[New Thread 0x7fffd3fff700 (LWP 6506)]
[Thread 0x7fffd3fff700 (LWP 6506) exited]
[Thread 0x7fffedb44700 (LWP 6497) exited]
[New Thread 0x7fffedb44700 (LWP 6525)]
[New Thread 0x7fffd3fff700 (LWP 6526)]
[New Thread 0x7fffd1483700 (LWP 6527)]
[Thread 0x7fffd3fff700 (LWP 6526) exited]
[Thread 0x7fffd1483700 (LWP 6527) exited]
[New Thread 0x7fffd1483700 (LWP 6528)]
[New Thread 0x7fffd3fff700 (LWP 6529)]
[Thread 0x7fffd1483700 (LWP 6528) exited]
[New Thread 0x7fffd1483700 (LWP 6538)]
[Thread 0x7fffd3fff700 (LWP 6529) exited]
[Thread 0x7fffd1483700 (LWP 6538) exited]
[New Thread 0x7fffd1483700 (LWP 6539)]
[New Thread 0x7fffd3fff700 (LWP 6540)]
[Thread 0x7fffd3fff700 (LWP 6540) exited]
[New Thread 0x7fffd3fff700 (LWP 6541)]
[Thread 0x7fffd3fff700 (LWP 6541) exited]
[Thread 0x7fffd1483700 (LWP 6539) exited]
[New Thread 0x7fffd1483700 (LWP 6542)]
[Thread 0x7fffd1483700 (LWP 6542) exited]
[New Thread 0x7fffd1483700 (LWP 6545)]
[New Thread 0x7fffd3fff700 (LWP 6546)]
[Thread 0x7fffd3fff700 (LWP 6546) exited]
[Thread 0x7fffd1483700 (LWP 6545) exited]
[New Thread 0x7fffd1483700 (LWP 6547)]
[Thread 0x7fffd1483700 (LWP 6547) exited]
[Thread 0x7fffe6c56700 (LWP 6501) exited]
[New Thread 0x7fffe6c56700 (LWP 6548)]
[Thread 0x7fffe6c56700 (LWP 6548) exited]
[New Thread 0x7fffe6c56700 (LWP 6549)]
[Thread 0x7fffe6c56700 (LWP 6549) exited]
[Thread 0x7fffed343700 (LWP 6498) exited]
[Thread 0x7fffe5217700 (LWP 6503) exited]
[Thread 0x7ffff7fa3700 (LWP 6496) exited]
[Thread 0x7fffe5ad9700 (LWP 6502) exited]
[Thread 0x7ffff7fb4980 (LWP 6492) exited]
[Inferior 1 (process 6492) exited normally]
/usr/lib64/libreoffice/program/gdbtrace:8: Error in sourced command file:
No stack.
Missing separate debuginfos, use: debuginfo-install gtk2-2.24.18-1.fc18.x86_64
quit

unfortunately this seems to be not available:

~>sudo debuginfo-install gtk2-2.24.18-1.fc18.x86_64
[...]
No debuginfo packages available to install

Hi marting,

We met same issue on Windows, but this has been fixed recenntly. Directory for backup was mssing. Please see:
Bug 65501 - FILESAVE Can not save a modified document with backups enabled

Thank you,

Jacques

It is a bit of a disappointment, that this bug has been creeping around since 2006. </rant>

I can confirm this. And I fail to have a good workaround. And I can confirm that the backup directory exists. And I can add some remarks:
1. It always works when I save to a new file name on the folder (mounted cifs)
2. It never works when I 'save' to the then existing file name. The .bak is actually created, on the local drive, but with a size of 0. Then it fails to update the file on the shared folder.
3. The best of the worse workarounds: I create two almost identical files on the drive, and 'toggle' to which I store; because if I have file1 open and work on it, I can always save as file2, and when I have file2 open, I can always save as file1. But having file1 open, I cannot save to file1 without the error message coming up; same with file2. Conclusion: it only fails if one wants to store to the same, open, file.

*** Bug 62556 has been marked as a duplicate of this bug. ***

*** Bug 67827 has been marked as a duplicate of this bug. ***

Changed version to oldest known (from bug 62556)

CONFIRMED here with LO 4.0.3 and LO 4.1.2.3 on Linux Mint Debian Ed.,  also on Win7.  Didn't really notice it with LO 3.x before,  but now it is permanent:  

Editing and saving a writer or calc file on a local ext4 or NTFS disk works;  the backup file on a local NTFS disk is correctly created.  All fine so far.

Editing and saving a writer or calc file on a CIFS mount (our common file server) fails with "Backup could not be created" while the backup file is created with a size of 0 (regardless whether it existed before or not).  Saving with backup disabled works.  

Moving my ~H:/config/libreoffice/4 and /3 away (thus forcing LO to create a  new blank profile) does not help.  

I regard this as a rather severe bug since it effectively blocks the use of the backup feature!  Because of this bug I just upgraded to 4.1.2.3,  but to no avail.  

Hans

FWIW:  our CIFS server is openSUSE 12.1, Samba version 3.6.3-34.11.1-2788-SUSE-SL12.1-x86_64 with unix extensions = no

*** Bug 80539 has been marked as a duplicate of this bug. ***

Two years now and no response…? 

I'd like to raise Importance to Major, since this bug effectively blocks LO from using backup files in a company environment!  

Hans

+1
It's huge inconvenience in a corporative environment/

(In reply to comment #20)

> I just found in my notes that I reported this bug for OOo-2.x

Thanks Eugene

Bug still the same on Fedora 23:

libreoffice-*-5.0.3.1-1.fc23.x86_64

backupfile: ~/.config/libreoffice/4/user/backup

though I wonder "4" is still used. I expected "5".

Error message and a zero byte backupfile are still the same.

I tried a different samba server (NAS), mounted:
type cifs (rw,relatime,vers=1.0,sec=ntlm,cache=strict,username=<****>,uid=1000,forceuid,gid=1003,forcegid,addr=<IP>,file_mode=0755,dir_mode=0755,nounix,serverino,mapposix,rsize=61440,wsize=65536,actimeo=1)

Correction.

Backup file created, but length=0:
[ses@ses-comp backup]$ pwd
/home/ses/.config/libreoffice/4/user/backup
[ses@ses-comp backup]$ ls -l
total 0
-rwxr-xr-x 1 ses ses 0 Feb 11 14:33 qq.bak

Fnd I don't understand why version subdirectory is "4" not "5".

Still defunct in 5.1.2.2.0+ / Linux!  

I would really wish that the LO team would spend time on fixing all those annoying year-old known bugs instead of just ignoring them and instead unnecessarily adding gimmicks or changing the UI…  

It's four years now and this bug still is a major hindrance in a company environment. 

If you really want LO not to be laughed at by all those MS Office users, please do give care and attention to the details.  I'm a strong advocate for FOSS, but I've ceased recommending LO to people using MS Office.

To us happened the same. Tjhe problem start yesterday when we got a power failure and some files opened over the samba network got size 0, and when we start libreoffice again it didn't ask to restore the file. So we went to the directory where the backups are stored (locally in the PC), but there are no bak files.

Server Ubuntu 14.04.2 LTS
samba [2:4.3.9+dfsg-0ubuntu0.14.04.3]

Client Ubuntu 16.04 LTS
LibreOffice 1:5.1.4-0ubuntu1 (Id. de compilación)

I encountered this problem years ago when using OpenOffice.org 2.X saving to a SMB server share on a Linux server at the time with a support contract. It was unsolvable then, and the only workaround was to turn off LibreOffice automatic backups.

Getting same bug on Windows 10.
LIBREOFFICE 5.4.4.2

Saving the document 
Error creating object
could not create backup copy

Received this message after multiple changes and saves of the same document.
Trying to save backup on a DVD drive.

still same issue with:

Version: 6.0.3.2
Build-ID: 6.0.3.2-5.fc28

Still same issue with 6.3.0.4.

However, there is a 9 year old (!) report (http://blog.gresch.de/2010/06/03/openofficesambacifs-probleme-could-not-create-backup-copy/) that suggests adding the "nobrl" option (no byte range lock) to the cifs mount options.

Given that this bug could not be fixed for a decade, but affects many users and this option bypasses it (at least in my case), wouldn't it make sense to add a hint like "(maybe try mount option nobrl?)" to the error message?

*** Bug 136592 has been marked as a duplicate of this bug. ***

Hello,

I am encountering this same issue. Here, some details:
- I am using Linux Manjaro (MATE Edition)
- I am using LibreOffice 7.1.1.2
- I have a SAMBA server on Armbian 21.02.3 Buster with Linux 5.10.21-rockchip64
- version SAMBA 4.9.5 (as reported by smdb -V)
- smb.conf is simple as possible (just specifying read only = no)
- on client, the share is mounted using AutoFS.
- the resulting mount is the following: 

//192.168.1.150/Data on /mnt/Data type cifs (rw,relatime,vers=3.1.1,cache=strict,username=alexandre,domain=WORKGROUP,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.1.150,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,_netdev)

I have noticed something else:
- if I open a file on the samba share with LibreOffice and I copy/paste the file using Caja (MATE file explorer), I have the following error: "Error during "splicing" operation on the file. Permission denied".

On pc Debian testing x86-64 with LO Debian package 7.3.4.2, I don't reproduce this.

Here what I did:
- created a local samba share
- launched Writer and create a brand new file
- saved it with name "test1.odt" on the local samba share
- enabled option "Always create backup copy"
- relaunched LO Writer
- opened test1.odt
- added some text
- saved it again
=> I got a non null file ~/.config/libreoffice/4/user/backup/test1.bak (8,7K).

Did I miss something or could someone may give a new try with LO 7.3.4?

This is definitely a bug in LO since at least version 7.0
Please see my thread regarding this issue. You might find a few useful information there.

https://ask.libreoffice.org/t/error-while-saving-documents-bugs/79081

10 years later :)

Still the same issue with libreoffice 7.3.4.2
Ubuntu 22.04

smb from NAS:
cifs    vers=1.0,x-systemd.automount,noauto,file_mode=0640,dir_mode=0750,credentials= ...

If this is a SMBv1 problem, this issue could be ignored. But I don't think so.

The "nobrl" (no byte range lock) cifs mount option works for me (see comment 37 https://bugs.documentfoundation.org/show_bug.cgi?id=55004#c37 ).  

From my /etc/fstab:  cifs   vers=3.0,nobrl,users,noauto,credentials=…

Still, I see this as a bug to be fixed.

Thank you for the feedback, I put it back to NEW since people can reproduce this.

Personnally I can't reproduce this.
In my /etc/samba/smb.conf, there's no line resembling to
systemd.automount,noauto,file_mode=0640,dir_mode=0750,credentials
I suppose it's because I know too little about smb so can't help here=>uncc myself.

Certainly someone may have some idea in the next 10 years :-)

Ah, thanks  HansPL!

nobrl is at least a work around!

No error occurs and a (non zero byte) backup file will be created:

tux :: 4/user/backup » ls -altr
insgesamt 20
-rw-r----- 0 Jul  1 12:19 test.bak
-rw-r----- 9175 Jul  1 13:12 test2.bak

I think, if you work with nautilus/etc without /etc/fstab entry, smb is mounted as gvfs and this also works.

Created attachment 181067 [details]
bt with debug symbols

Re reading about all this, I just remind I use Open/Remote instead of mounting the samba share.

I could reproduce this with master sources updated today and attached a bt at the moment of the throw.

(In reply to Julien Nabet from comment #47)
Julien's error is excep.Message = "folder exists and overwrite forbidden"

I would expect that utl::UCBContentHelper::ensureFolder would be able to catch the exception and acknowledge that this particular error indicates a valid folder (at least existing - but perhaps not user accessible).

*** Bug 156796 has been marked as a duplicate of this bug. ***

This problem is produced entirely on the @cifs@ protocol
As I read a little here, there is a nobrl function, but in contrast to it, I’ll say that during multi-user work with a file, the lock file flies away, in connection with which the file disappears on the network and it’s not even possible to restore it.
I'm looking forward to solving the problem
Данная проблема производится полностью на протоколе @cifs@
Как тут немного вычитал есть функция @nobrl@, но в противовес неё скажу, при многопользовательской работе с файлом улетает @lock файл@ в связи с чем происходит исчезновение файла на сети и не возможность даже восстановить.
Очень жду решения проблемы.

I have been editing various LibreOffice files on the Samba mounts for years. For last couple of years I did not change much in the set-up, except, obviously, updating the software. Suddenly, today I have noticed that I ran in into this issue. And I am certain that I edited the same file without any problems multiple times during last ~2 months, so the recent update of LibreOffice has made the error to appear (I never had it before).

Arch Linux, 6.7 kernel, LibreOffice 24.2.0.3, server - Samba, running on reasonably fresh Debian. Network share mounted via autofs. Problem observed with Calc.

Extra detail. Backup path is set to /data/home/<user>/.config/libreoffice/4/user/backup  (local path, but on another disk). I see that LibreOffice does create a zero-length backup file there successfully when I try to save the original file, but then, for some reason, fails to write it.

Changing this path to anything, any location, even /tmp, or selecting the option to save the backups in the same location as the original document does not change the end result - I always keep getting the same error and the 0-length file gets created in any of these locations. Must be a bug in LibreOffice and it is not related to Samba, apparently.

FYI only, some work is being done related to this bug, ref:
https://gerrit.libreoffice.org/c/core/+/162935

Additional observations:

Test:

1. Make test.ods file, save locally
2. Enable "Always create a backup copy" option (default path, under ~/.config/...)
2. Open with Calc, open the local test.ods file. 
3. Make a change, save. Observe that the backup file is properly created where expected, no complaints.
4. Close the file
5. Copy that file on a network share
6. Open the same file from the mounted network share
7. Make a small change, try saving. Observe the above-mentioned error. Backup file is re-created with 0 length.

Now, in addition to that, I have noticed that out of two Samba servers I have, the issue is reproducible only with ONE of them. They are different: one is Samba on Debian server, another one is Synology NAS. When I put the file on that NAS, the problem does not occur. Both are mounted in identical way on the client machine.

So, indeed, this hints about some kind of property that Libre Office reads from the original file and then trying to apply that property to the backup.

I will do more debugging to try to undestand what is it. There must be a filesystem syscall that fails somewhere.

> 
> Now, in addition to that, I have noticed that out of two Samba servers I
> have, the issue is reproducible only with ONE of them. They are different:
> one is Samba on Debian server, another one is Synology NAS. When I put the
> file on that NAS, the problem does not occur. Both are mounted in identical
> way on the client machine.

Please clarify the connection type cifs disks and the line itself in full for comparison.
And it’s not clear which problem exists and which doesn’t?
Просьба пожалуйста уточнить тип подключения cifs диски и саму строку полностью для сравнения.
И не ясно какая проблема есть, какой нет?

I did a bit of digging and narrowed down the problem to this:

[pid 638112] access("/mnt/networkshare/subdir/calc_doc.ods", F_OK) = 0
[pid 638112] newfstatat(AT_FDCWD, "/mnt/networkshare/subdir/calc_doc.ods", {st_mode=S_IFREG|0644, st_size=29563, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid 638112] newfstatat(AT_FDCWD, "/data/home/user/.config/libreoffice/4/user/backup/calc_doc.ods.bak", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid 638112] unlink("/data/home/user/.config/libreoffice/4/user/backup/calc_doc.ods.bak") = 0
[pid 638112] newfstatat(AT_FDCWD, "/mnt/networkshare/subdir/calc_doc.ods", {st_mode=S_IFREG|0644, st_size=29563, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid 638112] newfstatat(AT_FDCWD, "/data/home/user/.config/libreoffice/4/user/backup/calc_doc.ods.bak", 0x7fff1f3dacb0, 0) = -1 ENOENT (No such file or directory)
[pid 638112] openat(AT_FDCWD, "/mnt/networkshare/subdir/calc_doc.ods", O_RDONLY) = 20
[pid 638112] newfstatat(20, "", {st_mode=S_IFREG|0644, st_size=29563, ...}, AT_EMPTY_PATH) = 0
[pid 638112] openat(AT_FDCWD, "/data/home/user/.config/libreoffice/4/user/backup/calc_doc.ods.bak", O_WRONLY|O_CREAT, 0100644) = 33
[pid 638112] pread64(20, 0x7fff1f3d2c10, 29563, 0) = -1 EACCES (Permission denied)
[pid 638112] close(20)                  = 0
[pid 638112] close(33)                  = 0


This is what happens when saving a file with "Always create backup copy" enabled. Indeed, Samba locking makes the difference.

For some reason, in order to save a backup copy, LibreOffice actually tries to copy the original file while having it open. Samba blocks reading of that file (see pread() call). This is exactly what happens - it creates an empty file for the backup, but then fails to read the data to be copied.

Samba locking options are set to "yes" by default, including blocking locks.

smbstatus output for this file:

Locked files:
Pid          Uid        DenyMode   Access      R/W        Oplock           
3503         1006       DENY_NONE  0x12019f    RDWR       LEASE(RWH)

Both shares (one where the problem is reproducible and another one, where it is not) are mounted as follows:

credentials=/etc/smb-credentials/smd-cred-file,uid=user123,gid=user123,file_mode=0644,dir_mode=0755,vers=3.0,iocharset=utf8,noauto,x-systemd.automount,_netdev,x-systemd.idle-timeout=600

Kevin Ottens committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/63efbc8ad8aae12b54e649c1495d1233c1a9b33f

tdf#55004 Fix backup copy creation for files on mounted samba shares

It will be available in 24.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Kevin Ottens committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/a8814b5921676b1c01a19b0af243712c55fb0307

tdf#55004 Fix backup copy creation for files on mounted samba shares

It will be available in 24.2.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

*** Bug 159526 has been marked as a duplicate of this bug. ***