Bug 161446

Summary: Writer files containing images get corrupted when saving to CIFS Shares when SAMBA server has SMB2 Leases disabled
Product: LibreOffice Reporter: darren
Component: WriterAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED WORKSFORME    
Severity: normal CC: stephane.guillou
Priority: medium    
Version: 7.4.7.2 release   
Hardware: ARM   
OS: All   
See Also: https://bugs.documentfoundation.org/show_bug.cgi?id=141639
Whiteboard:
Crash report or crash signature: Regression By:

Description darren 2024-06-06 16:38:34 UTC 
Description:
Saving files to a CIFS share on a Samba Server with SMB2 Leases disabled will result in the file becoming corrupted. Attempted repair will fail.

The problem seems to occur if the images are resized by clicking and dragging on them. It also appears that several images need to be inserted for this issue to occur - although it could be that the size of the resulting .odt file is actually the triggering factor (I will do more testing to try and narrow this down). 

Samba servers tend to have SMB2 leases enabled by default. However, there are some distributions that do disable them for some reason. 
I have recreated on a Synology NAS system and a SAMBA server running on Raspberry Pi OS (Bookworm). 

The problem does not occur if you save the file locally or to a share on a SAMBA server that have SMB2 leases enabled.   

Steps to Reproduce:
1.Setup CIFS share on SAMBA Server with smb2 leases = no specified in the [global] section of the smb.conf file
2.Create a new Writer file and insert a number of images (desktop screenshots are fine) using insert>image  
3.Save the file to the CIFS share
4.Close Writer and re-open the file. It may already be corrupt.
5.If it isn't, resize some of the images by clicking on them and dragging
6. Repeat steps 3-5 until you receive dialog box informing you that file is corrupt.

Actual Results:
You will be informed that the file is corrupt and cannot be repaired

Expected Results:
You should be able to reopen the file and continue editing it.


Reproducible: Always


User Profile Reset: No

Additional Info:
I have IP packet traces of working and corrupt saves and am happy to provide these if they help (they are quite large).
Looking at these traces the behaviour is significantly different between working and failing examples. 
The working save uses an Oplock type of Lease and writes the entire .tmp file in one SMB write request (still multiple TCP packets obviously).
The failing/corrupt save uses several SMB Write requests that seem at times to overwrite parts of the previous data written. These write requests are also interspersed with SMB read requests. This may or may not be by design - but tome it's unusual.  
In both cases, the .tmp file is renamed to the original .odt file after save is complete.  

Finally, this may be the underlying cause of bug 141639 - it may be worth checking if SMB2 leases on the SAMBA server are disabled in that situation.
Comment 1 Stéphane Guillou (stragu) 2024-06-22 04:20:57 UTC 
Thank you for the report.
Version 7.4 is not maintained anymore. Some CIFS and SAMBA issues have been fixed since, for example bug 158975 and bug 55004.
Please test version 24.2.4 or above and let us know if you can still reproduce.
Thank you!
Comment 2 darren 2024-06-23 16:48:27 UTC 
(In reply to Stéphane Guillou (stragu) from comment #1)
> Thank you for the report.
> Version 7.4 is not maintained anymore. Some CIFS and SAMBA issues have been
> fixed since, for example bug 158975 and bug 55004.
> Please test version 24.2.4 or above and let us know if you can still
> reproduce.
> Thank you!

Hi there Stéphane,
Thank you for your comment. I can confirm that I have tested with v 24.2.4 and the issue is resolved.

As this V24 is not the default version for the Linux distro I am using, it's worth noting that the issue can be worked around in V7.4 by enabling SMB2 leases on the target Samba Server. This may help anyone that is experiencing the issue in 7.4 and is unable to upgrade straight away.

Thank you again - as per instructions, I will change back to UNCONFIRMED. Apologies if I should have marked as RESOLVED instead!
Comment 3 QA Administrators 2024-06-24 03:16:03 UTC Comment hidden (obsolete)
Comment 4 Stéphane Guillou (stragu) 2024-06-24 11:32:46 UTC 
Thank you for the reply and workaround!

As we haven't identified exactly what fixed it, I'm marking as "resolved - works for me" (but someone else is always able to shed some light or pinpoint exactly what fixed it, in which case we could duplicate to the relevant report or mark as "fixed").