LibreOffice Dateien werden über CIFS Freigabe (fstab) zerstört

[3faltigkeit]

Hallo Zusammen,

ich habe ein dubioses Problem mit der SMB-Freigabe meiner FritzBox 7490 (OS: 7.21).
SMB Version 1.0 ist an der FB nicht aktiv. Nur ein höhrers Protokoll. Welches sagt die GUI nicht aus.

Das Share wird mit der fstab eingehängt: //IP/Pfad /media/ordner cifs noperm,credentials/home/user/.datei 0 0
Das noperm habe ich nur drin, da er es sonst als read only einhängt.

Das Problem ist reproduzierbar. Ich erstelle eine .ods auf dem Netzlaufwerk. Öffne diese, schreibe Test rein und speichere.
Die Datei kann dann nicht geöffnet werden. Es kommt der LibreOffice Importer der nur kryptische Zeichen importieren kann.
Lokal auf der platte passiert das nicht. Eine planke (editor) Datei nur mit Text drin hat das Problem nicht. Der Libre Office Writer schon. Der zeigt dann nur "#".

Dateien öffnen und ohne speichern schließen funktioniert. Sobald man über die ein gehangene SMB-Freigabe aber etwas speichert (schreibt), ist die Datei Schrott. Auch ein Entspacken bzw. reparieren mit WinRAR funktioniert dann nicht mehr.

Von den Windows Rechnern aus funktioniert alles problemlos.
Das Linux ist ein ZorinOS 15.2 64 Bit (Ubuntu 18.04) mit den neusten verfügbaren Updates drauf.

Ich habe aktuell keine Idee dazu, eventuell fällt euch etwas dazu ein.


Besten Dank & viele Grüße

Edit: Die FB in 7.21 supportet SMB2 & SMB3.
Ich habe jetzt in der fstab mit vers=2.0 und vers=3.0 getestet.
Es ist immer das selbe Ergebnis. Die Protokoll-Version spielt keine Rolle.

Edit2: Ich sehe gerade er hängt beim speichern fest. Die Datei ist wahrscheinlich zerstört, da man beim speichern einfach beendet. Dann wäre die Farge, warum kann er nicht speichern...

Edit3: Ich habe jetzt mit smbclient vom Linux aus getestet und bekomme das hier:

Spoiler: smbclient -d 4 -L //192.168.5.201 -U ftpuser

lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[global]"
doing parameter workgroup = WORKGROUP
doing parameter server string = %h server (Samba, Ubuntu)
doing parameter dns proxy = no
doing parameter log file = /var/log/samba/log.%m
doing parameter max log size = 1000
doing parameter syslog = 0
WARNING: The "syslog" option is deprecated
doing parameter panic action = /usr/share/samba/panic-action %d
doing parameter server role = standalone server
doing parameter passdb backend = tdbsam
doing parameter obey pam restrictions = yes
doing parameter unix password sync = yes
doing parameter passwd program = /usr/bin/passwd %u
doing parameter passwd chat = Enter\snew\s\spassword:* %n\n Retype\snew\s\spassword:* %n\n password\supdated\ssuccessfully .
doing parameter pam password change = yes
doing parameter map to guest = bad user
doing parameter usershare allow guests = yes
pm_process() returned Yes
added interface enp2s0 ip=2003:a:30b:e800:e56e:df6d:c75d:1bc3 bcast= netmask=ffff:ffff:ffff:ffff::
added interface enp2s0 ip=192.168.5.103 bcast=192.168.5.255 netmask=255.255.255.0
Client started (version 4.7.6-Ubuntu).
Connecting to 192.168.5.201 at port 445
session request ok
negotiated dialect[SMB3_11] against server[192.168.5.201]
got OID=1.3.6.1.4.1.311.2.2.10
Enter WORKGROUP\ftpuser's password:
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
SPNEGO login failed: {Not Enough Quota} Not enough virtual memory or paging file quota is available to complete the specified operation.
session setup failed: NT_STATUS_NO_MEMORY

Die smb.conf schaut so aus:

Spoiler: smb.conf

# Global parameters
[global]
dns proxy = No
log file = /var/log/samba/log.%m
map to guest = Bad User
max log size = 1000
obey pam restrictions = Yes
pam password change = Yes
panic action = /usr/share/samba/panic-action %d
passwd chat = Enter\snew\s\spassword:* %n\n Retype\snew\s\spassword:* %n\n password\supdated\ssuccessfully .
passwd program = /usr/bin/passwd %u
server role = standalone server
server string = %h server (Samba, Ubuntu)
syslog = 0
unix password sync = Yes
usershare allow guests = Yes
idmap config * : backend = tdb

[printers]
browseable = No
comment = All Printers
create mask = 0700
path = /var/spool/samba
printable = Yes

[print$]
comment = Printer Drivers
path = /var/lib/samba/printers

 

[Guyinkognito]

Liest sich als wäre die Platte voll? Oder kann die Fritzbox Usern Speicherplatz zuweisen? Dann steht der für den User wahrscheinlich auf 0

Edith:
https://forums.opensuse.org/showthread.php/527178-smbclient-gives-NT_STATUS_NO_MEMORY

Heisst deine Arbeitsgruppe wirklich Workgroup?

 

[3faltigkeit]

Moin, nee da ist noch reichlich Platz. Von anderen Rechnern (mit Windows) funktioniert es mit dem Benutzer.
Ich habe jetzt zur smb.conf das hinzugefügt:

client use spnego = no
client ntlmv2 auth = no

Jetzt komme ich mit dem File-Manager Thunar aufs share drauf. Vorher hatte er den login immer verweigert, obwohl das PW etc. korrekt waren. Wenn ich dann dort ein Dokument anlege, war reinschreibe & speichere, dann ist es nicht zerstört. Die Ausgabe von smbclient hat jetzt auch den Fehler nicht mehr gebracht. Ich teste jetzt weiter mit der fstab.

Edit: Ja, Workgroup ist korrekt

Ergänzung (7. Oktober 2020)

Keine ahnung, per fstab bleibt das Problem. Wir haben für alle 4 Rechner hier den gleichen Benutzer an der FB. Nach Update der FB auf 7.21 und dem nicht mehr nutzen von SMB1 klappt das mit dem Linux einfach nicht mehr.

Ergänzung (7. Oktober 2020)

Jetzt habe ich einen anderen User auf der FB angelegt. Sonst wie gehabt. Ich kann auch Dokumente anlegen. Aber nicht öffnen: Veraltete Dateizugriffsnummer (file handle)....

 

[Linuximatrix]

Hallo, hatte das gleiche Problem. LibreOffice zerschiesst beim Speichern auf dem Fritz!Box NAS meine Dateien. Um das Problem mit einem Workaround zu lösen musst du beim mounten das SMB caching deaktivieren. Beim Update aufs neue Fritz!OS und Umstieg weg von SMB Protokoll Version 1 sind nun folgende 2 mount-Optionen hinzugekommen, damit der Zugriff wieder fehlerfrei funktioniert:

noserverino
cache=none

Füge diese beiden Optionen deinem Mount-Kommando hinzu! Danach geht es wieder. Ist leider nur ein Workaround, da so SMB caching nicht genutzt werden kann. Aber das Problem liegt wohl eher auf Serverseite und diese Konfiguration muss AVM anpassen.

Bzgl. der von LibreOffice "zerstörten" Dateien. Die lassen sich wiederherstellen ohne Datenverlust! Es wurden durch das fehlerhafte Caching einfach am Anfang der Datei zuviele Null-Bytes geschrieben. Vergleiche in einem Dateieditor mit einer korrekt abgespeicherten Office-Datei wie sie normalerweise ausschaut am Anfang und lösche in der "zerstörten" Datei alle Zeichen bis dahin. Danach kannst du sie wieder normal mit LibreOffice öffnen und alle Daten sind noch da. Und mit obigem mount-Anpassungen geht dann auch das Speichern wieder normal.

 

[3faltigkeit]

Hi, sehr cool Danke. Das mit den Nullwerten hatte ich schon herausgefunden. noserverino hab ich auch schon drin. Das mit dem cache ist mir neu. Das probiere ich mal aus. Hab bei AVM auch ein Ticket laufen. Ich reiche denen das mal als Hinweis nach. Warst du auch im Linuxmit User Forum zu dem Thema aktiv? Hab das mit dem Cache deaktivieren dort auch gerade gelesen.

 

[Linuximatrix]

... Warst du auch im Linuxmit User Forum zu dem Thema aktiv? ...

ja