shiro
Anmeldungsdatum: 20. Juli 2020
Beiträge: 960
|
Ich bitte den Hinweis doch ernst zu nehmen und nicht lapidar auf die Suchfunktion zu verweisen. Ich schreibe hier, weil die Suchfunktion halt keine befriedigende Lösung lieferte. Ich habe eine Fritzbox 7590 auf Version 07.20 aktualisiert und mit SMBv2 oder 3 durchaus Probleme.
Man kann zwar für den mount Befehl den Eintrag die fstab aufnehmen, wie es Dieter_Ubuntu beschrieben hat.
Hat man in der Fritzbox SMBv1 enabled, kann man dann auf das Share teilweise zugreifen. Wird SMBv1 disabled, erhält man den "stale file handle" bei file Zugriff (auf Deutsch lautet der Fehler: "Veraltete Dateizugriffsnummer (file handle)"). Dieses Problem kann man umgehen, indem beim fstab Eintrag die Option "noserverino" einträgt. So weit ist das ja alles bekannt. Allerdings ist hiermit das folgende Problem nicht bereinigt.
Versucht man z.B. per rsync Daten auf das "fritz.nas" zu sichern, scheint dies auf den ersten Blick zu funktionieren. Wer denkt, er hätte seine Daten nun gesichert, merkt bei einem erneuten rsync Aufruf, dass dies nicht der Fall war. Zwar wurden Daten übertragen aber die Zeitstempel im NAS nicht aktualisiert. Aus diesem Grund werden die gleichen Kopieraktionen immer wieder wiederholt. Das Problem hatte ich an den AVM Support gemeldet, allerdings von dort die Antwort erhalten, dass man das Problem nicht bei sich sieht, da es ja bei den "gängigen Betriebssystemen (Windows, Mac OS X, Android, iOS)" funktioniert. Man solle das Problem auf der Ubuntu Seite lösen. Wenn ich in der Fritzbox SMBv1 enable und in der fstab die Optionen "vers=1.0,noserverino" eintrage, funktioniert es allerdings wieder wie zuvor (07.12).
Der einzige Nachteil ist allerdings, dass die Laufzeit (time ->real) mit dieser Konfiguration ca 4x länger dauert als unter 07.12. Statt über fstab das fritz.nas zu mounten, kann man dies auch über "gio mount smb://fritz.box/fritz.nas" machen. Allerdings dauert der gleiche rsync Befehl dann >35x länger als mit dem über fstab gemounteten share (nach einer Laufzeit von mehr als 35x der fstab Variante habe ich den rsync abgebrochen). Dazu bekommt man dann auch noch die bekannten Fehler "rsync: failed to set permissions on "...": Operation not supported (95)", auf die ich hier aber nicht abheben möchte. Das Timestamp Problem bleibt aber auch bei dieser mount Variante bestehen. Hat jemand eine Idee, wie man ein Backup mittels rsync in Verbindung mit dem fritz.nas unter Firmware 07.20 zum Funktionieren bringen kann ohne den oben beschriebenen Weg (ver=1.0,noserverino und SMBv1) oder eine Rückkehr auf 07.12 einzuschlagen?
|
Ubunux
Anmeldungsdatum: 12. Juni 2006
Beiträge: 16428
|
Bitte den Verhaltenskodex (Abschnitt „Hijacking“) beachten und keine fremden Themen entführen!
|
shiro
(Themenstarter)
Anmeldungsdatum: 20. Juli 2020
Beiträge: 960
|
@Ubuntux
Ich bitte vielmals um Entschuldigung, dass ich gegen eine Forenregel unwissender Weise verstoßen habe. Ich wollte kein Hijacking durchführen denn der Foreneintrag traf gemäß Suche am besten mit dem von mir geschilderten Problem überein. Zur obigen Problembeschreibung habe ich noch ein paar Untersuchungen durchgeführt und festgestellt, dass rsync zwar die Timestamps auf dem NAS (SMBv >1) nicht aktualisiert, was bei SMBv1 durchgeführt wird. Ein "touch -r" lässt aber zu, die Timestamps manuell zu aktualisieren. Verwendet wird das rsync aus der Xubuntu 18.04 Version:
1
2
3
4
5
6
7
8
9
10
11
12
13
14 | tstusr@XFC-tstusr04:~/c/User/tstdir$ uname -a
Linux XFC-tstusr04 5.3.0-62-generic #56~18.04.1-Ubuntu SMP Wed Jun 24 16:17:03 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
tstusr@XFC-tstusr04:~/c/User/tstdir$ rsync --version
rsync version 3.1.2 protocol version 31
Copyright (C) 1996-2015 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, iconv, symtimes, prealloc
rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.
|
Kann es sein, dass hier ein Problem mit rsync existiert?
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7990
|
Ich glaube nicht, dass dies ein Problem von rsync ist. Zur Verwaltung der Timestamps über SMB werden die "UNIX Extensions" gebraucht, und diese funktionieren (derzeit noch) ausschließlich mit SMBv1. Die neuen POSIX Extensions ersetzen in SMBv3 die bisherigen UNIX Extensions. Doch leider gibt es bis jetzt noch keine stabile Version eines Samba-Servers, der die POSIX Extensions unterstützt. Es gilt jetzt abzuwägen, ob man lieber weiterhin das Protokoll SMBv1 mit seinen bekannten Sicherheits-Risiken nutzen oder die Timestamps von Hand aktualisieren will. Gruß – Max-Ulrich
|
shiro
(Themenstarter)
Anmeldungsdatum: 20. Juli 2020
Beiträge: 960
|
Diese Erklärung hört sich treffend an. Danke für die Info. Im Moment helfe ich mir mit der folgenden kleinen Erweiterung (touch -r für alle kopierten Dateien):
| rsync avu --delete $src/ $dst/ | grep -v "/$" | egrep -v "^(sen|tot|skip|$)" | tee /tmp/$$
cat /tmp/$$ | grep -v "^deleting" | xargs -i° touch -r "$src/°" "$dst/°
|
Wenn ich die aufgrund deines Hinweises bisher gelesene Diskussion hinsichtlich POSIX Extensions richtig verfolgt habe, sollte es dann ja mit den zusätzlichen mount Optionen "vers=3.1.1,posix" funktionieren. Dies werde ich mal testen (wohl wissend, dass es sich um keine stabile Samba-Server Version handelt).
Mit dem oben beschriebenen Code-Schnipsel kann ich aber übergangsweise leben.
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7990
|
sollte es dann ja mit den zusätzlichen mount Optionen "vers=3.1.1,posix" funktionieren.
Leider nicht unbedingt. Auf dem Client funktionieren die POSIX Extensions bei mount.cifs bzw. mount -t cifs…. Doch sie müssen ja auch auf dem Server funktionieren, und das ist nicht selbstverständlich.
|
shiro
(Themenstarter)
Anmeldungsdatum: 20. Juli 2020
Beiträge: 960
|
Deine Bedenken scheinen einzutreffen. Allerdings habe ich schon das Problem auf der Client-Seite. Zwar wird vers=3.1.1 unterstützt, jedoch nicht die posix Option. Ab welcher Version kann man cifs-util unter 18.04 nutzen, damit die Posix Extension auf der Client Seite vorhanden ist?
| cifs-utils/bionic-updates,now 2:6.8-1ubuntu1 amd64 [installiert]
|
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7990
|
Zwar wird vers=3.1.1 unterstützt, jedoch nicht die posix Option
Das habe ich zuerst auch gemeint. Doch mount.cifs überprüft anscheinend, ob der Server die POSIX Extensions unterstützt und setzt, falls dies nicht zutrifft, die Option posix zurück bzw. setzt, was damit identisch ist, automatisch die Option nounix . Ich weiß nicht, wie schwierig es ist, die POSIX Extensions in Samba zu realisieren. Es wundert mich, wie lange schon davon die Rede ist, ohne dass wirklich etwas geschieht. Antwort eines Entwicklers auf meine Anfrage: "There is not yet a stable Samba version with POSIX extensions for SMB3+, sorry. This is still being worked on."
|
shiro
(Themenstarter)
Anmeldungsdatum: 20. Juli 2020
Beiträge: 960
|
Ich habe bei AVM die Frage nach den "Posix Extensions" gestellt. Die Antwort zeigte allerdings, dass man das Thema eher nicht kannte. Dies bestätigt die Vermutung, dass die Fritzbox mit FW 07.20 die Posix extensions nicht implementiert hat. Die verhandelten Ergebnisse des mount.cifs mit "-o user=ftpuser,pass=**PWD**,uid=1000,gid=1000,noserverino" sind demnach ein "nounix".
| cat /proc/mounts | grep fritzbox
//192.168.146.1/fritz.nas /mnt/fritzbox cifs rw,relatime,vers=3.1.1,cache=strict,username=ftpuser,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.146.1,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=65536,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1 0 0
|
Ganz merkwürdig ist allerdings, wenn ich in der Fritzbox SMBv1 enable und mit "-o vers=1.0,user=ftpuser,pass=**PWD**,uid=1000,gid=1000,noserverino" mounte, erhalte ich auch ein "nounix".
| //192.168.146.1/fritz.nas /mnt/fritzbox cifs rw,relatime,vers=1.0,cache=strict,username=ftpuser,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.146.1,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=61440,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1 0 0
|
Dennoch werden die Timestamps in diesem Fall (vers=1.0) korrekterweise aktualisiert. Kann es sein, dass ich mit den Unix/Posix Extensions in eine falsche Richtung suche? Bis auf vers und rsize sind die Einträge ja gleich. Eine rsync mit "-vvv --debug=all" zeigt dass ein modtime auf den korrekten neuen Timestamp und danach ein rename gemacht wird.
| ...
(Server) Protocol versions: remote=31, negotiated=31(Client) Protocol versions: remote=31, negotiated=31
...
recv_files(x.xxx)
set modtime of .x.xxx.HIAK0I to (1596053926) Wed Jul 29 22:18:46 2020
renaming .x.xxx.HIAK0I to x.xxx
[receiver] send_msg_int(100, 1)
...
|
Dennoch zeigen "ls -l" und stat, dass die Timestamps noch die alten Werte aufweisen.
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7990
|
wenn ich in der Fritzbox SMBv1 enable und mit "-o vers=1.0,user=ftpuser,pass=**PWD**,uid=1000,gid=1000,noserverino" mounte, erhalte ich auch ein "nounix".
Die Optionen uid und gid sind im Widerspruch zu den UNIX-Extensions. Dennoch zeigen "ls -l" und stat, dass die Timestamps noch die alten Werte aufweisen.
Meines Wissens bleiben die TimeStamps genau dann erhalten, wenn sich beim Kopieren Benutzer und Gruppe (genauer UID, GID und Dateiattribute) nicht ändern. Wenn die UNIX Extensions bzw. POSIX Extensions aktiv sind, dann ist dies automatisch der Fall; wenn nicht, dann stimmen diese auf dem Server und Client in der Regel nicht überein. Sein kann dies aber trotzdem. Ähnliche Probleme mit den TimeStamps können unabhängig von Samba auch beim Kopieren auf interne FAT- und NTFS-Partitionen auftreten.
|
Rampler
Anmeldungsdatum: 24. Dezember 2021
Beiträge: 2
|
Hallo zusammen,
gibt es da mittlerweile was Neues ? Ich versuche gerade rsync auf dem Raspberry (bullseye) zu überreden mit der Fritzbox zu arbeiten. Funktioniert nur mit Vers=1.0.
Der Zeitstempel wird leider nur mit Version 1 richtig gesetzt. Zusätzlich gibt es ganz viele:
CIFS: VFS: bogus file nlink value 0 Mein Mount:
fritzbox -fstype=cifs,rw,file_mode=0775,dir_mode=0775,user=ftpuser,pass=xxxxx,noserverino,vers=1.0 ://192.168.1.1/fritz.nas/NAS VG Klaus
|
Rampler
Anmeldungsdatum: 24. Dezember 2021
Beiträge: 2
|
Leider hat sich das Verhalten mit der neuen 7.50 Firmware der Fritzbox auch nicht verändert ...
|