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

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

Hallo zusammen,

wir haben das Problem auch, und ich würde den Lösungsvorschlag gerne ausprobieren. Wenn ich das richtig verstanden habe, dann muss ich auf den Clients (Ubuntu 18.04) etwas ändern. Aber wo finde ich die richtige Stelle?

LG Alex

Hallo,

die mount-Befehle werden mit pam aufgerufen und sind im Paket linuxmuster-client-shares zu finden. Die Datei, die die Befehle enthält, sollte bei dir unter

/etc/security/pam_mount.conf.xml

liegen. Dort die rsize=65536 in alle Zeilen eintragen. Falls bei dir auch das noforcegid nicht dabei ist, auch das. Sonst funktionieren die Tauschverzeichnisse, etc. nicht. nobrl (No byte range locking) würde ich auch bei jedem eintragen.

Viele Grüße,
Helge

PS: Wir haben den Fehler seit her nicht mehr :smiley: . Scheint also zu klappen.

Zusammenfassung:

und

Ich kann das bestätigen, wir hatten den Fehler auch. Danke!