Bug 137394 - File is corrupt after save to SMB / CIFS share
Summary: File is corrupt after save to SMB / CIFS share
Status: RESOLVED DUPLICATE of bug 137230
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.0.1.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-11 14:26 UTC by Robert
Modified: 2020-12-24 12:48 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
corrupted empty file (10.81 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-10-11 14:26 UTC, Robert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert 2020-10-11 14:26:55 UTC
Created attachment 166268 [details]
corrupted empty file
Comment 1 Robert 2020-10-11 14:32:41 UTC
Hi!
when I save a file to a SMB share provided by a fritzbox, the file cannot be opened again by libfeoffice.

The same problem appears with writer and calc, with the version distributed by debian testing, as well as with the version that can be downloaded from libreoffice.com.

When copying a file from another drive to the cifs mounted location, it can be opened normally, until it is saved from libreoffice.
A corrupted file can however be unziped and ziped again, which makes it readable again by Libreoffice.

The line of the mount in /etc/fstab is:
//FRITZ-NAS/FRITZ.NAS /media/nas cifs users,credentials=/etc/samba/fb.auth,noserverino,gid=users,file_mode=0664,dir_mode=0775 0 0 #,vers=1.0 0 0

in /proc/mounts it appears as
//FRITZ-NAS/FRITZ.NAS /media/nas cifs rw,nosuid,nodev,noexec,relatime,vers=3.1.1,cache=strict,username=libiko,domain=WORKGROUP,uid=0,noforceuid,gid=100,forcegid,addr=192.168.0.1,file_mode=0664,dir_mode=0775,soft,nounix,mapposix,rsize=65536,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1 0 0
Comment 2 [REDACTED] 2020-10-11 15:55:01 UTC
No repro on 

Version: 7.0.2.2, Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994
CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5
Locale: de-DE (de_DE.UTF-8); UI: de-DE, Calc: threaded

NAS (Fritzbox) operating system: Fritz!OS 7.20
Comment 3 [REDACTED] 2020-10-11 16:38:07 UTC
I'm a littel bit concerned about cifs mount options "uid=0,noforceuid", which seems to be a resource for trouble, when username=libiko and which I'd assume *not* to have uid=0 (and on my working solution, this is definitely not the case and the mount is performed using my uid, and forceuid)
Comment 4 Robert 2020-10-12 19:35:22 UTC
Hi Uwe,

I have added the mount options uid=1000,forceuid to the fstab-line but it didn't change anything. The line in /proc/mounts now reads:

//FRITZ-NAS/FRITZ.NAS /media/nas cifs rw,nosuid,nodev,relatime,vers=3.1.1,cache=strict,username=libiko,domain=WORKGROUP,uid=1000,forceuid,gid=100,forcegid,addr=fd00:0000:0000:0000:464e:6dff:fe34:0927,file_mode=0664,dir_mode=0775,soft,nounix,mapposix,rsize=65536,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1 0 0

I tried with those versions of Libreoffice. I also tried both with LANG=C, but without any difference.
Version: 7.0.2.2
Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: de-AT (de_AT.UTF-8); UI: en-US
Calc: threaded

Version: 7.0.2.2
Build ID: 00(Build:2)
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: de-AT (de_AT.UTF-8); UI: de-DE
Debian package version: 1:7.0.2-1
Calc: threaded

FRITZ!OS: 07.20
Linux 5.8.0-2-amd64

Can you add your line from /proc/mounts, so that I can search for differences?
Quite possible that there is some problem with the mount, but I don't have troubles with other software.

BR Robert
Comment 5 Thomas 2020-11-24 06:42:05 UTC
Hello,

mounting the NAS with the option "cache=none" seems to solve the problem (workaround). See this bug report:
https://bugs.documentfoundation.org/show_bug.cgi?id=137230

*** This bug has been marked as a duplicate of bug 137230 ***
Comment 6 Justin L 2020-12-24 12:48:13 UTC

*** This bug has been marked as a duplicate of bug 137230 ***