ubuntuusers.de

Danke Ubunux, das habe ich nun gemacht und es funktioniert grob.

Ich halte fest:

(1) Altes umständliches CIFS-Verfahren per fstab/mount geht. Allerdings, beim Kopieren von Dateien auf die Fritzbox-Freigabe reagiert der Thunar (oder die Konsole) kaum mehr, bis das Kopieren fertig ist. Sehr ungut. Und schreibendes Rsync geht auch nicht, siehe unten bitte.

(2) Neueres elegantes GVFS-Verfahren (gio …) zeigt überhaupt nur etwas an, wenn in /etc/samba/smb.conf die zwei Zeilen client min protocol = NT1 und client max protocol = NT1 eingefügt wurden, bringt dann aber inkonsistente Dateien: mal Ordner, mal Datei, für ein- und dieselbe Datei. Ist also leider völlig unbrauchbar.

(3) Dieser ganze Firlefanz iegt am alten Samba1-Protokoll der mittel- und alten Fritzbox-Modelle.

–

P.S. zu Rsync: Wenn Rsync auf die Fritzbox-Freigabe schreiben will, kommt dieser Fehler:

rsync: failed to set times on "Fritzbox_Einhaengeordner/Datei.txt": Operation not permitted (1)

Das ging vorher mit GVFS tadellos, also Methode (2). Den Rsync-Parameter „--times“ wegzulassen, ginge zwar, doch bekommt dann eine Zieldatei nicht das Quelldateidatum, sondern das aktuelle; also transferiert Rsync beim nächsten Mal unzählige Dateien erneut. Mit dem zusätzlichen Schalter „--update“ wird die Sache besser, wo dann jede Datei übersprungen wird, wenn die Zieldatei neuer als die Quelldatei ist. Ist aber gleichzeitig gefährlich, weil wenn die Zieldatei kaputtgemacht wurde, aber ein neueres Datum hat, entgeht die Dateileiche dem sonstigen Scharfsinn von Rsync und man hat eine korrupte Sicherung.

Dieser ganze Firlefanz liegt am alten Samba1-Protokoll der mittel- und alten Fritzbox-Modelle.

So einfach ist es leider nicht! Denn außer FritzBox-Modellen verwenden noch einige andere ältere Geräte – NAS, Multimedia-Geräte usw. – das Protokoll SMB1 (cifs). Es widerstrebt mir, diese Geräte deshalb zu entsorgen wo sie doch sonst noch einwandfrei funktionieren. Ich sehe auch nicht, warum SMB1 für ein Heimnetzwerk ohne sensible Daten zu unsicher sein sollte. Das viel gepriesene NFS ist ohne zusätzliche Maßnahmen auch nicht sicherer – im Gegenteil!

Ein weiteres, wichtiges Problem ist, dass das Browsen in einem Samba-(Windows-)Netzwerk unabhängig vom verwendeten Dateimanager oder anderem Frontend (Gigolo, FuseSMB…) nur über das GIO und bislang nur mit dem Protokoll SMB1 funktioniert. Sich von SMB1 verabschieden heißt also, in Ubuntu (und jedem anderem Desktop-Linux) auf die Möglichkeit, im Netzwerk zu browsen, zu verzichten. Dies betrifft nebenbei nicht nur ältere Server und Geräte! 😢

In früheren Samba-Versionen (z.B. 4.7 in Ubuntu 18.04 LTS) war es mit einer einzigen Zeile in smb.conf möglich, die Verwendung von S MB1 zu ermöglichen:

  client max protocol = SMB1

In Samba 4.11 (Ubuntu 20.04) wird dies komplizierter. Um eine Kommunikation über SMB1 in beide Richtungen zu ermöglichen, müssen auch noch min protokol und client min protocol angepasst werden. Doch auch dies ist möglich, wenn auch komplizierter als bisher.

Doch ein weiteres Problem ist derzeit nicht gelöst: Bei der Verwendung von SMB1 werden offenbar Freigaben, die über das GIO eingebunden werden (GVFS, alle Dateimanager, FuseSMB, Gigolo…) inkonsistent. Dateien werden oftmals als leere Ordner dargestellt und somit unbrauchbar. Dies war bei früheren Samba-Versionen nicht der Fall. Dieses Problem ist viel gravierender als der andere "Firlefanz". So etwas dürfte eigentlich nicht passieren, besonders nicht bei einer LTS-Version!!

Der einzige Ausweg, im Zusammenhang mit Samba auf das GIO zu verzichten und das cifs-VFS zu verwenden (einbinden mittels fstab oder sudo mount -t cifs…), ist kompliziert und scheidet deshalb für viele Benutzer aus. Außerdem hat er andere Nachteile, z.B. das bekannte Shutdown-Problem.

Fazit: Als langjähriger Linux-User bin ich sehr enttäuscht!

Könnt ihr das bitte mal testen:

1

client min protocol = CORE

von dieser Seite: https://askubuntu.com/questions/1229929/cant-acces-nas-anymore-after-upgrading-to-20-04 unten in den Antworten

Normalerweise gilt laut smb.conf

The values CORE, COREPLUS, LANMAN1, LANMAN2 are silently upgraded to NT1.

D. h. CORE oder NT1 sollte egal sein, aber ja, man kann es mal testen. Ich komme frühestens erst am Wochenende dazu, mir das Verhalten in einer VM anzuschauen.

Edit: Bei gio mount gibt es wohl kein verbose, allerdings gibt es die Option detail. Kann einer der betroffenen mal die Ausgabe von

gio mount -i smb://fritz-nas/fritz

posten? Pfad logischerweise anpassen.

bitteschön:

gio mount -i smb://192.168.178.110/share
gio: smb://192.168.178.110/share/: Einhängen der Windows-Freigabe ist fehlgeschlagen: Das Argument ist ungültig

Das ist zwar keine Fritz!Box aber ein altes NAS, welches auch nur SMB1 versteht

Die Sache ist ärgerlich, aber eigentlich ganz einfach und auch einfach zu reparieren:

Ubuntu 20.04 verwendet Samba Version 4.11. In dieser Version ist für jeden SMB-Client, der die libsmbclient verwendet, das alte und bekanntermaßen unsichere Protokoll SMB1/CIFS deaktiviert. Dies geschieht über die Vorgabeeinstellungen, welche man so abfragen kann:

$ testparm -v -s | grep protocol
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_STANDALONE

	client ipc max protocol = default
	client ipc min protocol = default
	client max protocol = default
	client min protocol = SMB2_02
	server max protocol = SMB3
	server min protocol = SMB2_02

Ein SMB-Client unter Ubuntu 20.04 darf also alle Protokolle ab 2.02 verwenden. Eine Fritzbox beherrscht bis jetzt aber leider (abgesehen von Laborversionen) nur Protokoll Version 1, somit haben Server und Client kein gemeinsames Protokoll und die Kommunikation ist unmöglich.

Abhilfe: Man benötigt für die libsmbclient eine Konfigurationsdatei /etc/samba/smb.conf mit nur einer Zeile:

client min protocol = NT1 

Es dürfen natürlich weitere Einstellungen hier vorgenommen werden, aber zur Beseitigung des hier diskutierten Problems benötigt man nur diese einzige Zeile! Man sollte insbesondere die Protokoll-Versionen für den Server nicht ändern und auch nicht dem Client bessere Protokolle verbieten.

Mit dieser Einstellung kann ich auf meine Fritzbox 7490 per smbclient, nautilus und gio mount wie aus früheren Zeiten gewohnt zugreifen. Natürlich muss man die Client-Programme mit dem SMB-Benutzernamen und dessen SMB-Passwort versorgen.

Ich glaube, du hast den Thread nicht gelesen.

chr123 schrieb:

Ich glaube, du hast den Thread nicht gelesen.

Wie kommst Du denn darauf?

Ich habe den Thread sehr aufmerksam gelesen und parallel dazu das im Titel genannte Thema „Ubuntu 20.04 mag nicht mehr Fritzbox-Samba“ technisch analysiert, dafür eine maßgeschneiderte technische Lösung entwickelt und getestet.

Die Lösung ist einfach, wenn man erst einmal die Ursache verstanden hat. Beides habe ich erläutert.

Du kannst gerne andere, unnötig unsichere Lösungen präferieren. Ich kann jedenfalls unter Ubuntu 20.04 mit der einzeiligen Datei /etc/samba/smb.conf

client min protocol = NT1 

problemlos per smbclient oder per nautilus oder per gio mount den SMB-Server meiner Fritzbox 7490 erreichen. Gleichzeitig stellt dies die minimale Verschlechterung der Sicherheit dar, welche zur (Wieder-) Herstellung der Funktionalität erforderlich ist. Diese Verschlechterung muss man allerdings akzeptieren, solange AVM den SMB-Server in der Fritzbox nicht verbessert.

Andere Benutzer haben bereits die Zeile client min protocol und / oder client max protocol auf NT1 gesetzt und trotzdem keinen Zugriff, weil Dateien z. B. als Ordner dargestellt werden. Darum geht es.

Siehe hier.

Vor den Updates der ganzen Samba-Pakete vor 1-2 Tagen habe ich die hier vorgeschlagenen Lösungen auf einem alten NAS (welches auch nur SMB1 versteht) nicht getestet.

Nach den Updates hatte ich mit dem Eintrag client min protocol = CORE keine Probleme mit falsch angezeigten Dateien und Zugriff darauf, nach der Erklärung von chr123 habe ich es auch mit client min protocol = NT1 geprüft, dies macht keinen Unterschied, es funktioniert.

Wohlgemerkt, dabei handelt es sich nicht um ein FRITZ!NAS. Kann es sein, dass dies einen Unterschied macht, oder liegt es an den inzwischen aktualisierten Samba-Paketen?

chr123 schrieb:

Andere Benutzer haben bereits die Zeile client min protocol und / oder client max protocol auf NT1 gesetzt und trotzdem keinen Zugriff, weil Dateien z. B. als Ordner dargestellt werden. Darum geht es.

Nein. Darum geht es nicht in diesem Thread!

Der von Dir zitierte Aspekt ist eine Off-Topic-Diskussion in diesem Thread und hat wahrscheinlich mit der SMB-Problematik nichts zu tun. Die merkwürdigen Effekte – Dateien als Ordner dargestellt – wurden von mir nicht beobachtet und dazu habe ich bisher auch gar nichts gesagt.

Für mich geht es – vgl. Titel des Threads – hier nur um die SMB-Funktionalität. Ich kann diese in meinem Ubuntu-System mit einer einzigen Zeile wiederherstellen. Wenn das bei anderen Benutzer so nicht funktioniert, kann es z.B. an Fehlinterpretationen, Bedienfehlern oder wesentlichen technischen Unterschieden zwischen verschiedenen 20.04-Systemen oder an ganz anderen Ursachen liegen. Jeder mag selber prüfen, ob meine Methode bei ihm zum Erfolg führt.

@kB

Nach deiner kürzlichen Fehleinschätzung von Off-Topic-Beiträgen solltest du doch etwas gelernt haben, zum Glück bestimmst du nicht alleine, was Off-Topic ist und was nicht 😎

Du erklärst leider nicht, ob deine Erfolge nach der Aktualisierung der Samba-Pakete oder vorher erzielt wurden.

Nur zu vermuten oder zu spekulieren, warum manche hier diese Probleme mit den Dateien/Ordnern hatten, bringt niemand weiter, es wäre nett, wenn das mal jemand verifizieren könnte, ob diese Probleme nach der Aktualisierung der Samba-Pakete beseitigt sind.

Max-Ulrich_Farber schrieb:

[..]

Ja, das ist alles richtig. Es ist sehr ärgerlich. Insgesamt macht Ubuntu 20 LTS eine sehr unrunde Figur, bisher.

kB schrieb:

chr123 schrieb:

Andere Benutzer haben bereits die Zeile client min protocol und / oder client max protocol auf NT1 gesetzt und trotzdem keinen Zugriff, weil Dateien z. B. als Ordner dargestellt werden. Darum geht es.

Nein. Darum geht es nicht in diesem Thread!

Durchaus geht es auch darum in meinem Thema namens „Ubuntu 20.04 mag nicht mehr Fritzbox-Samba“.

Denn die Auf-die-Schnelle-Lösung

client min protocol = NT1

funktioniert leider nicht generell, wie einige hier, mich eingeschlossen, geschrieben haben: zwar verbindet der Samb1-Client mit unserem Ubuntu, aber des ersteren Dateitypen wechseln dann ständig, und ein Arbeiten ist damit unmöglich.

Wenn mal bei fünf Endbenutzern (auf 5+ Geräten) das absolut gleiche Problem im Zusammenhang mit Samba1 auftaucht, ist es jedenfalls kein Bedienfehler, soviel ist sicher.

Und das Dateityp-Wechselproblem habe ich an meinem Hauptrechner mit frisch installiertem Xubuntu 20, an einem zweiten Rechner, ebenfalls neu installiert, in einer virtuellen Maschine, auch frisch installiert.

Der von Dir zitierte Aspekt ist eine Off-Topic-Diskussion in diesem Thread und hat wahrscheinlich mit der SMB-Problematik nichts zu tun. Die merkwürdigen Effekte – Dateien als Ordner dargestellt – wurden von mir nicht beobachtet

Unser geschildertes Problem ist jedenfalls nicht nebensächlich (off-topic). Es hat für uns Endbenutzer mit dem Samba-Modul von Ubuntu zu tun, denn nur bei ihm sehen wir es. Woran es intern liegt, weiß doch keiner hier.
Die Dateien werden auch nicht nur in Intervallen optisch als Ordner dargestellt, sondern sind in Intervallen Ordner, dann wieder Dateien, usw, daher schreibt auch Rsync nicht mehr auf solche Samba1-Medien.

Kurzum: ein Arbeiten mit Ubuntu 20 und Samba1-Clienten ist momentan unmöglich. Also mag Ubuntu 20 das Samba1 der Fritzbox und allen möglichen anderen NAS-Geräten nicht mehr.

Fand jemand schon einen Fehlerbericht auf Launchpad?

@Udalrich

Magst du bitte mal auf meinen Vorschlag eingehen und zuerst dein System auf den neuesten Stand bringen (wegen den aktualisierten Samba-Paketen) und danach mal testen ob das Problem weg ist, einmal mit den beiden Einträgen in der smb.conf und dann auch noch mit nur einem Eintrag client min protocol = NT1

Hallo kB,

Ja, dein Lösungsvorschlag läuft!
Allerdings nur, wenn die smb.conf wirklich nur aus dem von Dir genannten "Einzeiler" besteht.

Das ist IMHO aber maximal ein Workaround - aber keinesfalls DIE generelle Lösung für das eigentliche Problem!

Gruß
Bournless