[GELÖST] Nautilus: mounten von Freigaben mit SMB2 und höher scheitert

[WKN]

Hallo zusammen,

ich habe hier eine gemischte Umgebung: "Fileserver" und ein weiteres System auf Buster, 1 x Stretch (HTPC), 3 x Ubuntu, 1 Windows 8.1, 2 x Windows 10 (ein ganz normaler 4-Personen-Haushalt...).

Der Fileserver stellt seine Freigaben per SMB zur Verfügung, Samba 4.9.1 Sicherheitshalber würde ich gern SMB1 ausschließen. Dem üblichen Rat folgend habe ich dazu in der smb.conf im Abschnitt [global] eingefügt

Code: Alles auswählen

   server min protocol = SMB2
   client min protocol = SMB2
   client max protocol = SMB3

Der Zugriff von allen Geräten aus gelingt weiterhin, wobei ich auf den meisten keine festen mounts verwende, sondern mittels Nautilus die Verbindung nur bei Bedarf herstelle per smb://server/freigabe unter Andere Orte - Mit Server verbinden. Unter Windows sinngemäß dasselbe.

Problem und Frage: Einzige Ausnahme ist der HTPC (Stretch). Dort gelingt dieses Vorgehen nicht mehr, sobald ich SMB1 ausschließe. Statt dessen meldet Nautilus "Zugriff auf den Ort ist nicht möglich - Einhängen der Windows-Freigabe ist fehlgeschlagen: Die Wartezeit für die Verbindung ist abgelaufen."

Die Ursache muss m.E. auf dem HTPC gesucht werden, da alle anderen Geräte ja funktionieren. Google und Co. haben nichts Hilfreiches geliefert, oder ich habe es nicht erkannt. Die Fehlersuche ist für mich schon deshalb schwierig, weil ich gar nicht genau weiß, wie Nautilus die Freigaben eigentlich genau verbindet.

Bereits unternommen habe ich:
- Backports-Kernel installiert; keine Änderung
- per mount -t cifs -o im Terminal mounted; Infos nachfolgend

Mit min protocol = SMB2 erhalte ich

Code: Alles auswählen

~# mount -t cifs -o vers=2.0,username=[usrnm],password=[pwd] //192.168.1.112/htpc_daten_2 /media/hlp
mount: Einhängen von //192.168.1.112/htpc_daten_2 auf /media/hlp ist fehlgeschlagen: Die Operation wird nicht unterstützt
~# dmesg | tail
[  200.510069] FS-Cache: Loaded
[  200.510573] Key type dns_resolver registered
[  200.527349] FS-Cache: Netfs 'cifs' registered for caching
[  200.527460] Key type cifs.spnego registered
[  200.527463] Key type cifs.idmap registered
[  200.534130] CIFS VFS: Dialect not supported by server. Consider specifying vers=1.0 or vers=2.0 on mount for accessing older servers
[  200.534140] CIFS VFS: cifs_mount failed w/return code = -95

Was mich schon mal überrascht, denn ich hätte erwartet, dass vers=2.0 genug ist, um die Vorgabe zu erfüllen. Das hingegen funktioniert aber immerhin:

Code: Alles auswählen

~# mount -t cifs -o vers=2.1,username=[usrnm],password=[pwd] //192.168.1.112/htpc_daten_2 /media/hlp
~# mount -t cifs -o vers=3.0,username=[usrnm],password=[pwd] //192.168.1.112/htpc_daten_2 /media/hlp

dmesg liefert dann auch nur noch:

Code: Alles auswählen

[  563.886454] CIFS VFS: error -95 on ioctl to get interface list

Was m.W. eine normale Wechselwirkung mit dem Verzicht auf SMB1 ist. Damit kann ich gut leben.

Wie komme ich jetzt dem Fehler in Nautilus auf die Spur? Ich hoffe, Ihr könnt mir einen Tipp geben. Fehlende Angaben liefere ich gerne nach. Evtl. etwas verzögert - der HTPC wird doch recht oft gebraucht.

Vielen Dank
Thomas

[jph]

Der Zugriff von allen Geräten aus gelingt weiterhin, wobei ich auf den meisten keine festen mounts verwende, sondern mittels Nautilus die Verbindung nur bei Bedarf herstelle per smb://server/freigabe unter Andere Orte - Mit Server verbinden. Unter Windows sinngemäß dasselbe.

Nautilus nutzt gvfs für den Zugriff auf SMB, und das kann m.W. nur SMBv1. Quelle/Beleg finde ich leider gerade nicht…

[WKN]

Hallo jph, Danke für Deine Reaktion. Dass Nautilus gvfs nutzt, ist schon mal eine gute Spur. Wie gesagt allerdings: Alle PCs außer eben der HTPC auf Stretch können weiterhin wie gewohnt per Nautilus zugreifen/mounten.

In Stretch habe ich:

Code: Alles auswählen

~$ dpkg -l gvfs* | grep ii
ii  gvfs:amd64      1.30.4-1     amd64        userspace virtual filesystem - GIO module
ii  gvfs-backends   1.30.4-1     amd64        userspace virtual filesystem - backends
ii  gvfs-bin        1.30.4-1     amd64        userspace virtual filesystem - binaries
ii  gvfs-common     1.30.4-1     all          userspace virtual filesystem - common data files
ii  gvfs-daemons    1.30.4-1     amd64        userspace virtual filesystem - servers
ii  gvfs-fuse       1.30.4-1     amd64        userspace virtual filesystem - fuse server
ii  gvfs-libs:amd64 1.30.4-1     amd64        userspace virtual filesystem - private libraries

In Buster:

Code: Alles auswählen

~$ dpkg -l gvfs* | grep ii
ii  gvfs:amd64      1.38.0-2     amd64        userspace virtual filesystem - GIO module
ii  gvfs-backends   1.38.0-2     amd64        userspace virtual filesystem - backends
ii  gvfs-common     1.38.0-2     all          userspace virtual filesystem - common data files
ii  gvfs-daemons    1.38.0-2     amd64        userspace virtual filesystem - servers
ii  gvfs-fuse       1.38.0-2     amd64        userspace virtual filesystem - fuse server
ii  gvfs-libs:amd64 1.38.0-2     amd64        userspace virtual filesystem - private libraries

Die Ubuntus sind auf 1.36 Irgendwo zwischen 1.30 und 1.36 müsste demnach die Funktionalität für SMB2+ hinzugefügt worden sein. Ich tue mich schwer, ein Change-Log zu gvfs zu finden - ist auch das erste Mal, dass ich so etwas suche . Was ich gefunden habe (1), hilft nicht recht weiter, ist womöglich aber verkürzt.
Ein Bugreport zu Ubuntu (2) deutet immerhin darauf hin, dass mit Version 1.34 SMB2+ ebenfalls noch nicht unterstützt wurde.

Wahrscheinlich hast Du also Recht und gfvs in Stretch kann das einfach noch nicht. In den den stretch-backports gibt es dazu m.W. nichts. Wenn nicht noch eine andere Idee auftaucht, dann ist mein Problem also gar kein Fehler. Ich warte noch etwas ab und setzte das Thema dann auf gelöst.

Vielen Dank! Wieder etwas hinzugelernt.

(1) https://github.com/GNOME/gvfs/blob/master/NEWS
(2) https://bugs.launchpad.net/ubuntu/+sour ... ug/1736721

[inne]

Ich tue mich schwer, ein Change-Log zu gvfs zu finden - ist auch das erste Mal, dass ich so etwas suche .

Code: Alles auswählen

apt-get changelog gvfs libsmbclient

[WKN]

*grmpf* Gute Güte, ich hab' echt noch viel zu lernen. Dafür schon mal Danke!

Hinweise auf Änderungen bei der Unterstützung der SMB-Protokolle seit gvfs 1.30 sehe ich dort allerdings auch nicht. Und apt-get changelog libsmbclient liefert scheinbar das changelog für Samba. Dort sollte SMB3 aber schon seit 4.0.0 drin sein. In Stretch ist Samba 4.5 Zudem: Der HTPC ist hier ja ohnehin nur Client. (Dort umgekehrt bereitgestellte Samba-Shares funktionieren zudem auch bei Ausschluss von SMB1).

Ein wenig nagt immer noch der Zweifel an mir, ob nicht bloß etwas verbogen ist am HTPC. Werd' mal noch eine Stretch-VM aufsetzen, wenn nicht doch noch Vernunft (unwahrscheinlich) oder Faulheit (wahrscheinlicher) siegen. Mal schauen, ob die sich auch so verhält. Wenn ja, habe ich Ruhe - und Ihr auch..

[jph]

Gerade diesen Bug gefunden: https://bugzilla.samba.org/show_bug.cgi?id=12876

Ich glaube, du kannst das Thema auf gelöst setzen, wenngleich es nicht wirklich gelöst ist.

[WKN]

Danke für den Link. Mein Englisch ist "eingeschränkt". Wie ich das Ticket deute, belegt es zumindest, dass das Listing der lokalen Netzwerkumgebung verloren geht bei SMB2+. Das Verhalten kenne ich auch von Windows, wenn dort die SMB1-Unterstützung fehlt oder entfernt worden ist. Ist ok für mich.

Mein Problem ist m.E. noch etwas spezieller: Auch wenn ich die SMB2/3-Ressource direkt anspreche per smb://server/freigabe gelingt der Verbindungsaufbau
- mit der Stretch-Maschine nicht,
- mit den Busters (und auch den Ubuntus (18.04) und den Windows-Maschinen) aber schon.
Irgendetwas scheint da in den älteren gvfs-Versionen noch zusätzlich zu haken, in den neueren aber nicht mehr. Dasselbe Verhalten zeigt auch eine neue Stretch-VM, die ich soeben installiert habe.

Wie auch immer: da in den neueren Versionen behoben und offenbar auch kein spezifisches Problem meines HTPC, setze ich das Thema hier auf gelöst/geklärt und lege mich wieder hin.

Danke für Eure Hilfe! Wieder einiges dazu gelernt.

[jph]

Ich habe bei mir daheim Samba nahezu vollständig durch NFSv4 ersetzt. Funktioniert prima mit systemd-Automounts und Kerberos 5. Die Medienordner werden zusätzlich ohne Kerberos read-only freigegeben, womit ein LibreElec problemlos klarkommt.
Samba wird nur noch da eingesetzt, wo es unbedingt erforderlich ist (iTunes-Backups mit einer Windows-VM).

[WKN]

Verflixt - NFS, systemd und Kerberos! Das sind in einem Satz gleich drei Dinge, von denen ich keine Ahnung habe. Wird sinnvoll sein, dass ich mich damit mal beschäftige und die ganze Sache neu organisiere. Dafür hast Du mir jetzt jedenfalls schon mal eine gute Spur gelegt.