Copy von einem Samba share zu einem anderen erzeugt unendlich große Dateien

Ausgangssituation:

  • Ein Benutzer meldet sich auf einem LinuxClient an.

    • Das Script /usr/bin/create-desktop-icons aus dem Paket linuxmuster-client-extras endet nicht.
    • Bei der Analyse fällt auf, dass ein cp Prozess von /home/share/teachers/.Desktop auf den Desktop des Anwenders ein paar .desktop-Dateien kopiert.
    • Der Desktop des Anwenders liegt per Symlink auf Home_auf_Server.
    • Im Desktopordner des Anwenders entstehen korrespondierende Desktop-Dateien, die den gesamten verfügbaren Speicherplatz auf Home_auf_Server füllen (>1TB).
  • Dieses Verhalten tritt nicht bei jedem Login auf, aber mehrmals täglich. Irgendwann scheinen alle Benutzer alle .desktop-Dateien in ihrem Home_auf_Server/Desktop zu haben und Problem verschwindet, bis eine .desktop-Datei in /home/share/teachers/.Desktop neu angelegt wird.

  • Im Zuge dieses Problems kommen Fehlerbeschreibungen von Anwendern neu in den Blick, die Dateien mittels nemo von Home_auf_Server nach Tauschen_auf_Server kopiert haben und der Kopierprozess auch dort nie beendet wurde.

    • Die Ursache scheint also nicht im Script /usr/bin/create-desktop-icons zu liegen.
    • Zumal die Aufrufparameter von cp in der Prozessliste unauffällig erscheinen.
  • Alle Clienten sind per Kabel über Switche mit dem Server verbunden.

  • samba ist auf dem Server in Version 2:3.6.25-0ubuntu0.12.04.10+ta5 installiert. Dies erscheint mir die neuste Version zu sein.

  • Der Fehler ist alt: etwa ein 1 Jahr. Er wurde ignoriert, da er sich in unser Situation meist selbst heilt.

  • Kernelversion des Clients 4.4.0-143-generic

  • mount options auf dem Clienten:

    //10.16.1.1/fh on /home/teachers/fh/Home_auf_Server type cifs (rw,nosuid,nodev,relatime,vers=1.0,cache=strict,username=fh,domain=CBO,uid=0,noforceuid,gid=0,noforcegid,addr=10.16.1.1,unix,posixpaths,serverino,mapposix,nobrl,acl,rsize=1048576,wsize=65536,echo_interval=60,actimeo=1,user=fh)
    //10.16.1.1/shares on /home/share type cifs (rw,nosuid,nodev,relatime,vers=1.0,cache=strict,username=fh,domain=CBO,uid=0,noforceuid,gid=0,noforcegid,addr=10.16.1.1,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,echo_interval=60,actimeo=1,user=fh)
    
  • evtl. interessante dmesg-Ausgaben des Clienten:

    [1852409.104713] FS-Cache: Loaded
    [1852409.143512] FS-Cache: Netfs 'cifs' registered for caching 
    [1852409.143947] Key type cifs.spnego registered
    [1852409.143955] Key type cifs.idmap registered
    [1852420.256077] CIFS VFS: Autodisabling the use of server inode numbers on \\10.16.1.1\backup. This server doesn't seem to support them properly. Hardlinks will not be recognized on this mount. Consider mounting with the "noserverino" option to silence this message.
    

Kennt jemand dieses Verhalten und hat gar eine Lösung?

Hallo Frithjof,

hast Du servergespeicherte Profile konfiguriert. Jedenfalls passiert das was Du beschreibst mit dieser Konfiguration.
Gruß

Alois

Der Desktopordner wird via symlink auf Home_auf_Server gespeichert. Dies wird von den Linuxmuster-Skripten gemacht; ich habe also in der Datei /etc/linuxmuster-client/profile/usersettings.conf u.a. folgende Zeile:

  .Desktop:Desktop

Somit werden also Dateien von einem Share auf ein anderes Share kopiert. Dies sollte meines Erachtens so funktionieren. Kannst du mir etwas näheres sagen, z.B. Warum geht das schief?

Hallo Frithjof,

es soll Leute geben die alles auf den Desktop ablegen. Da ist dann auch Mal ein 4G ISO-Image dabei und das wird auch kopiert.

Wir sind deshalb seinerzeit weg von Server gespeicherten Profilen.

Gruß Alois

Ich glaube, wir sprechen aneinander vorbei. Ich beschreibe mein Problem noch einmal anders:

 echo "Hallo" > /home/share/teachers/.Desktop/winzig_kleine_datei.txt
 cp  /home/share/teachers/.Desktop/winzig_kleine_datei.txt /home/teachers/fh/Home_auf_Server/Desktop 

Diese Befehle erzeugt in einigen Fällen riesige Datei im Zielort. Obwohl die Quelldatei nur wenige Byte groß ist, dauert der cp-Prozess ewig an und endet erst, wenn der Speicherplatz im Zielort komplett belegt ist. Dieses Phänomen scheint nur aufzutreten, wenn Quelle und Ziel zwei verschiedene Samba-Shares sind.

Hallo Frithjof,

da muss ich passen.

Gruß

Alois

Hallo Frithjof,

tritt das Phänomen auch auf wenn du rsync an Stelle von cp verwendest?

Viele Grüße
Thomas

Ich werde das testen.

Schon vorweg: Das Problem tritt auch mit dem Dateimanager Nemo auf. Auch hier ist nicht jede kopierte Datei betroffen und oft klappen ganze Kopierprozesse. Aber dann und wann kommt auch Nemo nicht zum Schluss und Dateien auf dem Zielshare wachsen über alle Grenzen.

Ich habe die Quotas überprüft: Keiner der betroffenen Benutzer ist im Quotalimit. Ich schließe daher Quota als Ursache aus.

Kopiere ich die Dateien direkt auf dem Server, scheint das Phänomen auch nicht aufzutreten. Ich habe die Dateisysteme mittels fsck überprüft. Sie sind fehlerlos.

Hallo Frithjof,

die shares stammen vom gleichen Server oder unterschiedlichen?
Wie werden sie eingehangen? Wird beim mount ein SMB-Protokoll z.B. vers=2.0 als Option mitgegeben? Hat der ausführende Benutzer auf beiden shares die gleichen Windows-Berechtigungen?
Sind die Verzeichnisse per bind-mount eingebunden?

Viele Grüße
Thomas

vom gleichen Server.

mittels pam_mount aus den Linuxmuster-client Paketen.

ja, vers=1.0

Diese Frage verstehe ich nicht. Ich kann mit dem Begriff Windows-Berechtigungen nichts anfangen.

Meines Wissens macht der Client ein “normalen” Mount mittels mount.cifs. Auf dem Server entstehen keine zusätzlichen bind- mounts, wie es vor Jahren einmal der Fall war. Meinst du das?

Hallo Frithjof,

ja, das mag verwundern, aber auf einem Samba-Share gelten Windows-ACLs. Ist aber hier unerheblich, da du ja beide Shares per pam_mount holst, dann sind die Berechtigungen gleich, da der gleiche Benutzer.

Ich wollte mir nur ein genaues Bild machen. Hätte ja sein können, die Laufwerke stammen von verschiedenen Servern und werden per fstab gemountet. Oder sonst wie.

Tritt das Problem auch auf, wenn du das Samba Protokoll auf Version 2 änderst?

Viele Grüße
Thomas

Ich meine, vers=1.0 war notwendig, damit die Shares überhaupt bei neueren Kerneln mounten. Ich werde das überprüfen.

Nachdem es lange ruhig war, tauchte das Problem heute wieder auf:

  • /usr/bin/create-desktop-icons erzeugt terabyte-große Dateien, bis der Speicherplatz verbraucht ist.
  • die Quelldateien in /home/share/teachers/.Desktop sind wenige KB groß.
    -das Ziel ist immer ein Symlink auf einem Sambashare /home/teachers//Einstellungen/Desktop

/usr/bin/create-desktop-icons basiert bei uns immer noch auf cp. Entsprechend des Vorschlags habe ich es jetzt auf rsync umgebaut. Das sieht jetzt so aus. Ich fand den Programmierstil ja etwas gewöhnungsbedürftig. Habe ich hier eine Funktionalität übersehen?

#!/bin/bash
#Script created by Rainer Rössler (roesslerrr-at-web.de)
#License: Free Software (License GPLv3)

cd ~

RECHNER=hostname

HEIMAT=pwd

mkdir -p „$HEIMAT/Desktop“
#existieren Desktop-Einträge lokal?
[ -d /usr/share/linuxmuster-client/Desktop ] && rsync -a /usr/share/linuxmuster-client/Desktop/ „$HEIMAT/Desktop/“

#existieren Desktop-Einträge schulweit ?
[ -d /home/share/school/.Desktop ] && rsync -a /home/share/school/.Desktop/* „$HEIMAT/Desktop/“

#existieren Desktop-Einträge fuer Lehrer ?
[ -d /home/share/teachers/.Desktop ] && rsync -a /home/share/teachers/.Desktop/* „$HEIMAT/Desktop/“

exit 0

vers=1.0 ist beim Mounten der Sambashares gegenüber dem LML-Server notwendig. Mit vers=2.0 werden die Shares nicht gemountet. Ich nehme einfach an, der Sambaserver des LMLs ist einfach zu alt.

Hallo,
ist bei mir auch manchmal so, aber nur, wenn ich es von der Konsole aus mache. Da ich der einzige an der Schule bin, der sowas macht (ich habe auch keine Scripte, die sowas machen), stört es nicht weiter, von Nautilus / Nemo aus passiert es nie.
Ich setze auf mehr private Zeit und LMNv7 :slight_smile:
LG
Max

Hallo Frithjof,

ich glaube, die Lösung gefunden zu haben:

sudo mount -t cifs -o username=USER,rw,nosuid,nodev,nofail,nobrl,vers=1.0,noforcegid,rsize=65536 //10.16.1.1/USER /home/teachers/USER/Home_auf_Server

rsize muss kleiner als 131072 sein. Ich habe hier die Hälfte genommen.

Bei uns ist das Problem beim Kopieren von Tausch sporadisch, dann aber massenhaft aufgetreten. Eine besonderen Situation hat sich dann als reproduzierbar herausgestellt. Ich hoffe, dass das wirklich der gleiche Effekt ist:

  1. Öffne auf Home_auf_Server ein LibreOffice Dokument
  2. Während das Dokument geöffnet ist, kopiere die Datei auf deinen Rechner.
  3. Das endlose Kopieren beginnt.
  4. Dasselbe mit geschlossenen LibreOffice kopiert die Datei richtig.

Ein strace auf den Kopiervorgang (strace cp Home_auf_Server/Datei.odt /blabli) zeigt

mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f55accb5000
read(3, "PK\3\4\24\0\0\10\0\0tb|O\205l9\212.\0\0\0.\0\0\0\10\0\0\0mi"..., 131072) = 131072
write(4, "PK\3\4\24\0\0\10\0\0tb|O\205l9\212.\0\0\0.\0\0\0\10\0\0\0mi"..., 131072) = 131072
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072
...
...

Ein richtiges Kopieren sieht so aus, Datei ist 6956 Byte groß:

mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5883b56000
read(3, "PK\3\4\24\0\0\10\0\0tb|O\205l9\212.\0\0\0.\0\0\0\10\0\0\0mi"..., 131072) = 6956
write(4, "PK\3\4\24\0\0\10\0\0tb|O\205l9\212.\0\0\0.\0\0\0\10\0\0\0mi"..., 6956) = 6956 

Vermutung: Neuere cifs-clients setzen die rsize auf 1Mbit, wenn Sie erkennen, dass der Server die POSIX extensions und damit auch large POSIX reads anbieten. Das scheint bei Samba-server 3.6.25 wohl nicht richtig umgesetzt zu sein. Oder bei den Linuxclients wird die readsize nicht richtig umgesetzt. Getestet habe ich mit Ubuntu 18.04LTS und Debian Buster. Übrigens tritt der Fehler nur mit mount.cifs auf; einbinden mit smb:// liefert keine Fehler. Spricht eigentlich für client-Fehler.

Bei den Einstellungen des Sambaservers konnte ich auch nichts finden, was das falsche Kopieren behebt. Bleibt also nur die rsize des clients zu ändern.

Wie gesagt, ich hoffe, dass das alles auch für die sporadischen Kopierfehler gilt. Das wird sich dann in den nächsten Wochen zeigen.

Viele Grüße,
Helge

3 „Gefällt mir“

Sehr coole Arbeit!

ich werde den Parameter ausprobieren und nach deiner Technik Kopierfehler provozieren.
Gruß
Frithjof

Hallo Frithjof,

danke für die Rückmeldung und das Lob :slightly_smiling_face:

Schön, dass du das testen willst. Bin gespannt, ob der Fehler auch bei dir reproduzierbar ist.

Auf dem Server habe ich noch in der /etc/samba/smb.conf

   socket options = TCP_NODELAY SO_SNDBUF=65536 SO_RCVBUF=65536
   max xmit = 65535

eingetragen. Das ist wahrscheinlich ein bischen Voodoo-Glauben, aber schaden tut es nicht. Habe es heute mit einer kleinen Schülergruppe getestet und da war alles unauffällig. :crossed_fingers:

Viele Grüße,
Helge