Siduction Forum > Software - Support

[DE] Timestamp beim Kopieren auf Samba-Share

(1/4) > >>

d146:
Hi Leute,

ich weiß nicht mehr, wo ich noch suchen soll - vielleicht weiß von Euch jemand Rat.

Server:
Debian 10, Kernel: 4.19.0-10-amd64, Samba: 4.9.5+dfsg-5+deb10u1

Client:
Siduction, Kernel: 5.13.13-1-siduction-amd64, Samba/smbclient: 4.13.5+dfsg-2

Problem:

Ich habe auf dem Client verschiedene Samba-Shares des Servers gemountet. Bis ca. Anfang August wurde beim Kopieren auf diese Shares der originale Timestamp der Dateien erhalten (dafür werden verschiedenste Programme verwendet: cp, mc, Double Commander etc.).
Irgendwann danach muss es auf dem Siduction-Client durch eines der Updates eine Änderung gegeben haben, wodurch jetzt alle auf den Server kopierten Dateien ca. 1-2 Sekunden nach dem Kopiervorgang den Timestamp der aktuellen Uhrzeit erhalten (das zeigt sich auch, wenn man sich diese Dateien direkt auf dem Server auflisten lässt, sprich nicht übers Netzwerk/Share).

Wo ich das seither ebenfalls bemerke: Wenn ich in Geany eine Datei unter einemneuen Name auf einem dieser Shares speichere, kommt nach ebenfalls 1-2 Sekunden vom Editor der Hinweis, dass die Datei auf dem Share neuer sei als die, die ich gerade editiere ...

Tests auf anderen Clients, die diese Shares ebenfalls verwenden, zeigen dieses Verhalten hingegen nicht. Es handelt sich bei diesen Systemen z. B. um ein aktuelles Linux Mint oder auch ein Windows 10.

Die Konfiguration von Samba auf dem Server und auch die mount-Optionen auf Siduction sind seit laaanger Zeit nicht geändert worden - alles hat bisher einwandfrei funktioniert.

Ich wühle mich nun durch verschiedenste Quellen, Hinweise etc. (Bugzillas von kernel.org, Samba, Foren usw.), aber finde keinen wirklichen Hinweis (und übersehe den entscheidenden hoffentlich nicht ...).

Wie geschrieben: Kennt von Euch zufällig jemand dieses Verhalten und insbesondere vielleicht die kürzliche Änderung, die dazu geführt hat?

Bin für den Tipp sehr dankbar.

Viele Grüße

devil:
Ich habe dieses Verhalten noch nicht bemerkt, ich nutze aber auch kein Samba, sondern AutoFS/NFS. Zum Eingrenzen des Problems kannst Du ja mal versuchen, ob das Verhalten auf Samba beschränkt ist.

der_bud:
Ich krieg nicht mehr zusammen wo ich die Infos genau herhabe, vielleicht liefer ich Dir neue SuFu-Stichwörter ;)
Wenn das bei Dir "vor einiger Zeit" auftrat, kann das vielleicht mit einem Wechsel auf das Protokoll SMBv2 oder SMBv3 zusammenhängen, wo vorher Cifs Version 1 genutzt wurde. Obwohl v1 als veraltet und unsicher gilt, schalten viele User das explizit wieder an in Umgebungen, wo zum Beispiel alte Fritzboxen oder XP-Clients noch mitspielen. Es ist möglich, dass das korrekte Schreiben von Timestamps mit Änderungen der Optionen zusammenhängt.
Such mal nach mount-Optionen für die fstab, mit denen man die zu verwendete samba Version forciert, und vergleich das Verhalten mit Version 1 vs 2/3/default vs (wie devil vorschlägt) als NFS gemountet.

--
P.S. Siehe auch https://wiki.ubuntuusers.de/mount.cifs/#SMB-Protokoll-Versionen, Zitat:
"Zeitstempel
Sind die cifs-UNIX-Erweiterungen aktiv, dann wird beim Kopieren oder Verschieben von Ordnern und Dateien der Zeitstempel (Datum, Uhrzeit) genau so übertragen, wie wenn sich Ursprung und Ziel im gleichen Dateisystem befinden würden. Andernfalls wird der Zeitstempel nur dann übertragen, wenn die Besitzer auf dem Server und dem Client übereinstimmen; sonst gelten die kopierten Dateien als neu angelegt."

d146:
Hallo devil und der_bud,

vielen Dank für Eure Antworten!


--- Quote from: devil on 2021/09/05, 21:17:47 ---sondern AutoFS/NFS. Zum Eingrenzen des Problems kannst Du ja mal versuchen, ob das Verhalten auf Samba beschränkt ist.

--- End quote ---
Hatte ich schon mit NFS getestet, da mein SAT-Receiver so angebunden ist: da bleibt beim Kopieren der Timestamp erhalten, alles OK also.


--- Quote from: der_bud on 2021/09/06, 08:41:16 ---Ich krieg nicht mehr zusammen wo ich die Infos genau herhabe, vielleicht liefer ich Dir neue SuFu-Stichwörter ;)

--- End quote ---
;-)


--- Quote ---Wenn das bei Dir "vor einiger Zeit" auftrat, kann das vielleicht mit einem Wechsel auf das Protokoll SMBv2 oder SMBv3 zusammenhängen, wo vorher Cifs Version 1 genutzt wurde.
--- End quote ---
Ja, das ist einer der Punkte, den ich schon abgeklopft hatte: Das läuft schon länger mit SMBv3, sollte also nicht die Ursache sein. Wie gesagt: konfigurationsseitig habe ich da seit gefühlten Ewigkeiten nichts geändert. Aber natürlich können sich irgendwann mal Defaults ändern, deswegen hatte ich zunächst u. a. auch Samba selbst im Verdacht. Ich habe aber mal die term.log-Files in /var/log/apt untersucht: Das letzte Samba-Update (auf eben 4.13.5+dfsg-2) fand Mitte Mai statt, kann also nicht die Ursache sein. Denn danach habe ich haufenweise Fotos auf den Server kopiert (bei der gleichen Aktion am vergangenen WE habe ich übrigens das neue Verhalten überhaupt erst so richtig bemerkt), bei denen das originale Datum&Uhrzeit korrekt erhalten geblieben sind.


--- Quote ---Such mal nach mount-Optionen für die fstab, mit denen man die zu verwendete samba Version forciert, und vergleich das Verhalten mit Version 1 vs 2/3/default vs (wie devil vorschlägt) als NFS gemountet.

--- End quote ---
NFS: s. o.
SMB v2: hatte ich schon getestet: gleiches Bild
SMB v1: hatte ich noch nicht getestet, weil eben Security etc., aber jetzt gerade mal damit versucht, und siehe da: damit bleibt der Timestamp erhalten ...


--- Quote ---P.S. Siehe auch https://wiki.ubuntuusers.de/mount.cifs/#SMB-Protokoll-Versionen, Zitat:
Andernfalls wird der Zeitstempel nur dann übertragen, wenn die Besitzer auf dem Server und dem Client übereinstimmen; sonst gelten die kopierten Dateien als neu angelegt."[/tt]

--- End quote ---
Genau, u. a. diesen Wiki-Artikel hatte ich ebenfalls bereits durchgeackert: Die Übereinstimmung der Owner auf Server und Client ist bei mir seit jeher gegeben. Auch von dieser Seite kann es also eigentlich nicht kommen.

Bleibt momentan nur, die Suche auf SMBv1 vs. die neueren zu fokussieren. Evtl. kann ich damit das Problem damit weiter eingrenzen. Insbesondere werde ich mir das Linux Mint noch mal genauer anschauen und vergleichen, denn mit dem funktioniert ja nach wie vor alles wie gewohnt.

Vielen Dank also noch mal an Euch. Ich berichte, falls ich was herausfinde.

whistler_mb:
Das könnte bei mir erklären, warum seit dem Ende des Freeze Fehlermeldungen in LibreOffice kommen, wenn ich Dateien auf einem Samba-Share öffne und diese dort wieder speichere. Dort kommt dann die Meldung, dass die Datei auf dem Server neuer ist, als die, die ich speichern möchte.

Das war vorher nicht so. Mit den Linux-Mint Rechnern im gleichen Netz gibt es diese Meldungen nicht.

Navigation

[0] Message Index

[#] Next page