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