ods corrupt (cifs mounted)

Hello,

I updated my Linux Mint to 20.0 and LibreOffice to

Version: 6.4.6.2 Build-ID:
1:6.4.6-0ubuntu0.20.04.1 CPU-Threads:
12; BS: Linux 5.4; UI-Render:
Standard; VCL: gtk3; Gebietsschema:
de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: CL

After that I had corrupted ods files after saving the good ones.

I created a test.ods with “test” in it and saved it in a file in my local directory named täst.ods to check for utf naming conversion.
Then I saved it on a cifs mounted partion, too. The filename is fine.
The size of the files differ (7.4 kByte local / 11.5kByte on cifs).
If I try to open the file on the cifs mounted partion Calc tries to import it as csv UTF-16 or others.
Neither of them leads to a readable version.

What is the reason for the corrupt ods file?
I opend both files with hexedit and the bigger one has 0x1000 zeros before

00001000   50 4B 03 04  14 00 00 08  00 00 03 58  27 52 85 6C  PK.........X'R.l
00001010   39 8A 2E 00  00 00 2E 00  00 00 08 00  00 00 6D 69  9.............mi
00001020   6D 65 74 79  70 65 61 70  70 6C 69 63  61 74 69 6F  metypeapplicatio
00001030   6E 2F 76 6E  64 2E 6F 61  73 69 73 2E  6F 70 65 6E  n/vnd.oasis.open
00001040   64 6F 63 75  6D 65 6E 74  2E 73 70 72  65 61 64 73  document.spreads
00001050   68 65 65 74  50 4B 03 04  14 00 00 08  00 00 03 58  heetPK.........X

I mounted the usb stick of my FritzBox in fstab

//192.168.178.1/FRITZ.NAS /media/Fritzbox cifs credentials=/etc/samba/auth.192.168.178.1.ftpuser,vers=3.1.1,uid=1001,gid=1003,file_mode=0774,dir_mode=0775,iocharset=utf8 0 0 

Any idea?

The difference in size accounts for the 0x1000 zeroes (4k). What happens if you manually remove the first 4k zeroes? Do you recover the file?

Of course, this doesn’t explain why the zeroes have been added to the file.

The error is always the same, every time.
I do not think, that cutting the zeros will give a solution, because the files also differ later on.

I did some other test and found

  • similar problems with Writer and odt files,
  • no problems with Writer exporting as pdf,
  • no problems with using other ext4 mounted partitions,
  • no problems with other applications (xed, Drawing) using the cifs mounted partition.

This is not a solution to your problem, rather a follow-on to my comment.

According to site rules, please use the more link at bottom of your “non-answer” to Repost as a comment. Only you, as answer owner, can see this more link and only you can click on it.

Version: 6.4.6.2 Build-ID: 1:6.4.6-0ubuntu0.20.04.1

This combination is highly suspect to me, if regarding new installations of LibreOffice on Ubuntu 20.04 based Linux systems and using Ubuntu repositories. This site is full of issues related to this combination of LibreOffice/Distribution, which all seem completely unrelated and all share the same solution: Complete de-installation + autoremove in a terminal and fresh installation of LibreOffice. (I’m also using a FritzBox and using CIFS mount to my openSUSE Linux system and can’t verify the behavior).

I de-installed the complete LibreOffice suit and installed it again as flatpack.
Now I have

Version: 7.0.4.2
Build ID: dcf040e67528d9187c66b2379df5ea4407429775
CPU threads: 12; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Flatpak
Calc: threaded

Errors are the same. (If I delete the zeros the file is usable)

Then the question boils down to: what adds the zeroes?

Which driver manages the cifs mount?

Which driver manages the cifs mount?

No special driver - CIFS client is a Linux VFS kernel module.

I used CIFS/SMB in the past without issue. I changed for ftp(s) so that I can freely exchange files between my computers, even when I’m away.

Tested now on

Mint 20, Version: 6.4.6.2, Build ID: 1:6.4.6-0ubuntu0.20.04.1, CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US,Calc: threaded

and could not repro the issue (FRITZ!OS: 07.20).

But @JoeAsks stated (which is a little bit an incorrect statement, since FritzBox exports the filesystem and not the hardware):

I mounted the usb stick of my FritzBox in fstab

I don’t use an USB device on my FritzBox, but using the internal storage (just for testing purposes). Hence it might be related to USB.

I have the exact same issue. Running OpenSUSE 15.2 with LibreOffice Version: 6.4.5.2.

Looks like someone found a workaround:

Disable the caching of the filesystem using cache=none

Since FritzOS 7.2 the SAMBA server is not used anymore for SMB. Instead a QNA server is used and there seems to be issues with the caching. So disabling the caching option when mounting the device worked for me.

When using fstab to mount the Fritz.NAS add the no cache option as following:

//192.168.178.1/FRITZ.NAS/ /home/{user_name}/fritzNAS cifs credentials={your_credentilas},noserverino,cache=none,uid=1000,gid=1000 0 0

I can create and edit LibreOffice documents again. No trailing 0 are added to the document anymore.

Ok, looks like someone found a workaround:

Disable the caching of the filesystem using cache=none

Since FritzOS 7.2 the SAMBA server is not used anymore for SMB. Instead a QNA server is used and there seems to be issues with the caching. So disabling the caching option when mounting the device worked for me. I can create and edit LibreOffice documents again. No trailing 0 are added to the document anymore.

Thanks for your contribution!

Please note that above, you have exactly reversed the correct way to answer/comment here. This is a Questions-and-Answers site, where for each question, people provide answers (solutions), so each answer must be a solution to the original question/problem, not a “me too”-like comment. The latter should be the comment (not answer!), or a separate question (where you are free to link to previous similar questions for the reference/context).

But then you made a comment, where in fact you actually provide a valid and valuable solution - so please edit your answer, and replace your question with this information. That way, it might be actually useful to others looking for solutions for this problem.

Thank you!

Ah, thanks for the info. I must admit I did not read the board rules in it’s totality.
I changed by answer and hope it now fits your expectations at least to such a degree that it’s allowed to stay there. If not feel free to delete my answer.
The first comment I made I could not edit anymore.

There’s no apparent reason why saving to a cifs mounted device should prepend 4k of zero bytes (the excerpt you gave of the following data looks like a valid ODF zip container). Try if it happens again when saving to that drive, or when copying the original file to the drive.

I deleted the zero bytes and calc opened the file without problems.
I saved it again and the zeros were there again.