ubuntuusers.de

Seit etwa einem Monat (Mai 2016 bis Juni 2016) habe ich massive Probleme via GVFS auf CIFS-Freigaben (Agorum Core) überhaupt noch zugreifen zu können. Bis dahin konnte ich via GVFS über Los und der Eingabe

1

smb://192.168.100.210/dms

auf den Server nach Eingabe der Anmeldedaten zugreifen. Dann ein Lesezeichen drauf, wunderbar. Genau so war es auch erwünscht, denn auf dem Server kommen ACLs zu Einsatz, das temporäre Einbinden nach einem Anmelden als Benutzer und mit Passwort ist so erwünscht, denn der Benutzer der Station ist nicht immer gleich Benutzer für den Zugriff auf den Server. Warum ich das so explizit darstelle, erklärt sich nachfolgend.

Wie man unter https://www.samba.org/samba/history/ sehen kann, gab es am 12 April 2016 bedeutsame Updates und am 02 May 2016 Samba 4.3.9 (Available for Download), so auch der Samba-Client (Version 4.3.9-Ubuntu). Ich kann derzeit nur spekulieren, dass es hier einen Zusammenhang gibt.

Ein erster Workaround, damit ich nach dem Update überhaupt wieder zugreifen konnte war ein Eintrag in die /etc/samba/smb.conf unter der Sektion [global]:

1

client use spnego = no

Dieser Eintrag hat sofortige Wirkung, der Zugriff mit dem gewohnten Anmeldebild war erfolgreich. Dies liegt wohl daran, dass das Schema smb in GVFS die Funktionalität von smbclient nutzt. Auch ist das temporäre Einbindung ohne Root-Rechte, dass GVFS ja bietet, hier genau das was ich benötige.

Der Zugriff auf den Server ist derart drastisch verlangsamt, dass ein Arbeiten mit dem Server zur Qual wird.

Ein weiterer Workaround gibt mir zwar die volle Performance wieder und belegt dass es hier keine anderweitigen Probleme, wie z.B. die Netzwerkverbindung gibt, jedoch ist die Lösung nicht wirklich praktikabel.

Unter Samba Client cifs ist eine Möglichkeit beschrieben, via mount.cfs auf die CIFS-Freigabe zugreifen zu können. Mit dem folgenden Eintrag unter /etc/fstab gelang mir dann ebenfalls der Zugriff (on demand):

//192.168.100.210/dms /media/dms cifs noauto,users,rw,sec=ntlm,username=mister-x,password=geheim 0 0

Ein Klick auf das unmittelbar nach dem Eintrag verfügbare Netzwerk im GVFS und ich habe den Zugriff auf das DMS mit der vollen Leistung. Der Wert noauto sollte eigentlich ermöglichen, dass die Ressource nur zum Einhängen vorgemerkt ist und dann beim Versuch, auf die Ressource zugreifen zu wollen, sich ein Anmeldefenster öffnet, dass Benutzer und Passwort abfragt. Dazu habe ich testweise die Parameter username und password weggelassen bzw. leer gelassen. Aber keine Chance, es kommt leider kein Anmeldefenster.

Ich habe auch zeitgleich beide Methoden eingesetzt, man kann hier wunderbar sehen, dass der eine Zugriff mit voller Geschwindigkeit läuft und bei dem anderen sogar beim simplen Wechseln des Verzeichnisses jedes Mal die Einblendung "Ladevorgang" unten rechts eingeblendet wird.

Meine Frage ist nun, ob es noch mögliche Einstellungen in der smb.conf gibt, die wieder die volle Geschwindigkeit herstellen. Ich habe bisher nichts gefunden.

Mir würde hier zumindest helfen, den Eintrag in der fstab zu belassen, wenn dann Benutzer und Passwort beim Einbinden abgefragt würde. Ja, mir ist auch klar, dass mit SUID auf mount.cifs eine Sicherheitslücke mehr besteht. Aber zunächst kann ich auf dem Server nichts verändern.

Für die Client-Seite ist das eventuell noch einen Versuch wert: http://charlieharvey.org.uk/page/slow_nautilus_browse_with_netbios

Ansonsten scheint das ein bekanntes Problem zu sein, dass gvfs/smbget langsamer ist als ein normaler Mount: https://bugzilla.samba.org/show_bug.cgi?id=10879

Zu smb kann ich Dir leider gar nicht behilflich sein.

Allerdings hört sich Dein Scenario an, als ob Du mit sshfs die gleiche Funktionalität erreichen könntest. Ich bin vor einiger Zeit darauf gestoßen, und greife inzwischen ohne weitere Konfiguration damit auf all meine Maschinen im Netzwerk zu.

lionlizard schrieb:

Zu smb kann ich Dir leider gar nicht behilflich sein.

Allerdings hört sich Dein Scenario an, als ob Du mit sshfs die gleiche Funktionalität erreichen könntest. Ich bin vor einiger Zeit darauf gestoßen, und greife inzwischen ohne weitere Konfiguration damit auf all meine Maschinen im Netzwerk zu.

Danke für den Hinweis, dies setzt nach meinem Verständnis aber zumindest einen sftp-Dienst auf dem Server voraus. Ich bezweifle derzeit, dass dies im Fall von Agorum Core der Fall ist. Aber ich werde dies noch prüfen.

seahawk1986 schrieb:

Für die Client-Seite ist das eventuell noch einen Versuch wert: http://charlieharvey.org.uk/page/slow_nautilus_browse_with_netbios

Ansonsten scheint das ein bekanntes Problem zu sein, dass gvfs/smbget langsamer ist als ein normaler Mount: https://bugzilla.samba.org/show_bug.cgi?id=10879

Danke für die Hinweise. Ich habe dies getestet, also in /etc/nsswitch.conf den Wert wins unter hosts hinzugefügt. Leider ohne Erfolg, die Performance bleibt gleichermaßen schlecht.

Der Bug ist älter das Auftreten des Problems in meinen Installationen. Es mag sein, dass auch vorher schon die Leistung etwas eingeschränkt war, was aber eben nicht weiter aufgefallen ist.

Erst nach den letzten Updates, wo seit dem April 2016 im Samba-Client im Bezug auf Sicherheitsaspekte das Standardverhalten maßgeblich geändert wurde, habe ich diese massiven Probleme. Das kann zusammenhängen, muss aber nicht. Denn mein erster Workaround funktioniert ja mit GVFS wenn auch mit sehr schlechter Performance und auch mount.cifs kommt ebenfalls ohne die Option sec=ntlm nicht auf den Server, aber hier fehlt mir der Vergleich, wie es vor dem Update war. Hier gibt es irgendwie einen Zusammenhang, der sich mir nicht erschließt. Greift der smbclient und mount.cifs auf die gleiche Funktionsbibliothek zu? Wenn ja,mit welchen unterschiedlichen Optionen?

Ich fürchte, dass Problem liegt tiefer im aktuellen smbclient verborgen.

Greift der smbclient und mount.cifs auf die gleiche Funktionsbibliothek zu? Wenn ja,mit welchen unterschiedlichen Optionen?

Ja, aber die beiden virtuellen Dateisysteme cifs-vfs und GVFS, und damit die jeweiligen Einbinde-Vorgänge, funktionieren grundverschieden. Es gibt allerdings ein paar Optionen der Datei smb.conf, die sich in beiden Fällen auswirken. Das kann auch die Authentifikation betreffen. Es ist ganz schwierig, hier allgemein gültige Aussagen zu machen, denn das GVFS arbeitet ja "Dienste-übergreifend", d.h. nicht nur mit Samba.

Bei einigen Stellen in diesem Thread habe ich den Eindruck, dass da das GVFS und das cifs-vfs vermischt wurden, z.B.:

Unter Samba Client cifs ist eine Möglichkeit beschrieben, via mount.cfs auf die CIFS-Freigabe zugreifen zu können. Mit dem folgenden Eintrag unter /etc/fstab gelang mir dann ebenfalls der Zugriff (on demand):

//192.168.100.210/dms /media/dms cifs noauto,users,rw,sec=ntlm,username=mister-x,password=geheim 0 0

Ein Klick auf das unmittelbar nach dem Eintrag verfügbare Netzwerk im GVFS und ich habe den Zugriff auf das DMS mit der vollen Leistung.

Vermutlich wurde da nicht das GVFS verwendet, sondern auf die bereits mittels cifs-vfs eingebundene Freigabe zugegriffen. Und anscheinend sind die Einstellungen auf dem Server so, dass das cifs-vfs damit keine Probleme hat, wohl aber das GVFS. Da sehe ich noch nicht recht klar. Vielleicht fällt mir noch etwas ein ...

Gruß – Max-Ulrich

Max-Ulrich_Farber schrieb:

Bei einigen Stellen in diesem Thread habe ich den Eindruck, dass da das GVFS und das cifs-vfs vermischt wurden, z.B.:

Unter Samba Client cifs ist eine Möglichkeit beschrieben, via mount.cfs auf die CIFS-Freigabe zugreifen zu können. Mit dem folgenden Eintrag unter /etc/fstab gelang mir dann ebenfalls der Zugriff (on demand):

Hmm, evt. habe ich das etwas unverständlich dargestellt. Ich verstehe das GVFS als Kern der Oberfläche des Programms mit dem wenig charmanten Namen Dateien. So sollen hierüber auf Dateisysteme verschiedener Arten unter einheitlicher Oberfläche zugegriffen werden können. Dazu gibt es Schemen, wie z.B. FTP, SMB, die wenn man z.B. über Los in der Syntax [Schema]:[URI] manuell eingeben kann, um ein mounten derartiger externer Systeme zu ermöglichen, ohne eben über sonst üblich Root-Rechte verfügen zu müssen. So werden auch eingebaute Festplatten, angeschlossene USB-Geräte, wie Smartphone, USB-Stick, CD/DVDs eben einheitlich verfügbar gemacht.

Wenn ich also meine, dass ich via GVFS auf das via mount.cifs zur Verfügung gestellte Netzlaufwerk zugreifen kann, dann meine ich, dass eben diese in der fstab eingetragene Ressource unmittelbar in dem Programm Dateien unter der Rubrik Netzwerk mit dem Namen des mountpoint zur Verfügung steht. Sofern Benutzer und Passwort fest hinterlegt ist, kann ich hierauf auch zugreifen, sofern nicht, gibt es hier leider keine Abfrage, wie sonst üblicherweise über das Schema SMB erfolgt. Evt. ist das ein Denkfehler und sich muss das Programm Dateien von GVFS von der Betrachtung her strikt trennen.

Auch ist es wichtig, festzuhalten, dass beim Einbinden via mount.cifs die Optionen in fstab berücksichtigt werden und scheinbar keinesfalls die Optionen in /etc/samba/smb.conf. Ich kann dies nur aus der Beobachtung ableiten, dass der Wert sec=ntlm zwingend mit angegeben werden muss. Die Option client use spnego = no in der smb.conf unter [global] reicht nicht aus, um via mount.cifs die Freigabe tatsächlich ohne sec=ntlm zu mounten.

Evt. hilft es, einen Zugang zu GVFS zu erhalten, also die verwendeten Konfigurationsdateien. Evt. kann man ein eigenes Schema (z.B. CIFS) definieren, um so GVFS dazu zu überreden, mount.cifs für das mounten zu nutzen, zumindest um Benutzer und Passwort abzufragen, was leider nicht erfolgt. Optimal wäre ein gleichartiges dynamisches mounten ohne die Erforderniss der Root-rechte, so wie eben unter SMB.

Alternativ würde es helfen, die Parameter für den smbclient zu erhalten, die eben diese Perfomance-Probleme beseitigen. Mir will einfach nicht einleuchten, dass nach einem Update des smbclients mit einem Mal so massiv hier bei CIFS-Freigaben die Leistung runtergeht. Ich denke auch, dass eben GVFS direkt nichts mit zu tun hat, sondern eben diese schlechte Leistung vom smbclient erhält.

Ja, ist schon klar, alles wilde Spekulation, aber ich suche hier dringend Abhilfe, weil diese mangelhafte Perfomance einerseits und auch das Workaround via fstab andererseits suboptimal sind. Ich werde wohl auch eine 12.04 LTS Installation mal testen, ob hier die gleichen Problem vorliegen. Am Server selbst habe ich derzeit keine Möglichkeit, etwas zu verändern.

Ich verstehe das GVFS als Kern der Oberfläche des Programms mit dem wenig charmanten Namen Dateien. So sollen hierüber auf Dateisysteme verschiedener Arten unter einheitlicher Oberfläche zugegriffen werden können.

Das ist fast richtig, aber eben leider nur fast.

Das GVFS ist nicht die Oberfläche, mit der man auf alle Dateien zugreift, und auch nicht deren Kern. Es gibt Dateien oder Dateisysteme (auch ganze Partitionen, Freigaben usw.), die systemweit eingebunden sind – zum Beispiel statisch über einen Eintrag in /etc/fstab oder eben temporär mit dem Befehl mount. Die Dateimanager und die Anwendungsprpgramme können dann auf diese Ordner und Dateien direkt zugreifen, ohne dass dies mit dem GVFS etwas zu tun hätte.

Das GVFS bietet nun dem jeweils eingeloggten Benutzer die Möglichkeit, individuell auch noch auf solche Dateien, Dateisysteme usw. zuzugreifen, die nicht schon systemweit eingebunden sind. Das Einbinden dieser Dateisysteme erfolgt grundverschieden vom systemweiten Mounten, auch in einer völlig anderen Syntax (z.B. smb://...). Nur damit auch bestimmte Anwendungen, die mit dieser Syntax nicht klar kommen, zugreifen können, wird die so eingebundene Freigabe über FUSE an einem Mountpunkt (im Ordner /run/user/<IP des Users>) zusätzlich noch ins lokale Dateisystem eingebunden. Dies ist also ein ganz anderer Vorgang.

Um die Benutzer nun nicht mit Details zu belasten, die sie in der Regel gar nicht zu verstehen brauchen, stellen nun die Dateimanager die bereits systemweit eingebundenen Freigaben und diejenigen, auf die man zusätzlich noch über das GVFS zugreifen kann, (leider) gleich dar.

Wenn ich also meine, dass ich via GVFS auf das via mount.cifs zur Verfügung gestellte Netzlaufwerk zugreifen kann, dann meine ich, dass eben diese in der fstab eingetragene Ressource unmittelbar in dem Programm Dateien unter der Rubrik Netzwerk mit dem Namen des mountpoint zur Verfügung steht.

Das stimmt so also nicht. Ich hoffe, dass dies aus der obigen Erklärung einigermaßen verständlich (?) hervorgeht.

Evt. hilft es, einen Zugang zu GVFS zu erhalten, also die verwendeten Konfigurationsdateien. Evt. kann man ein eigenes Schema (z.B. CIFS) definieren, um so GVFS dazu zu überreden, mount.cifs für das mounten zu nutzen, zumindest um Benutzer und Passwort abzufragen, was leider nicht erfolgt.

Das kann also so grundsätzlich nicht gehen. Hier bewegt man sich auf zwei ganz verschiedenen Ebenen.

Optimal wäre ein gleichartiges dynamisches mounten ohne die Erfordernis der Root-Rechte, so wie eben unter SMB.

Etwas Ähnliches geht allerdings schon, doch eben nur ohne das GVFS. Die Berechtigung hierfür muss dann aber durch einen entsprechenden Eintrag in /etc/fstab erteilt werden. Mit dem GVFS hat das dann jedoch nichts zu tun. Man kann Freigaben, für die dieses durch einen entsprechenden Eintrag in fstab mit den Parametern users,noauto gestattet wird, jederzeit auch ohne Root-Rechte mit den Befehlen mount bzw. umount ein- und aushängen. Die Passwort-Angelegenheit kann man z.B. über eine versteckte credentials-Datei erledigen. – "Dynamisch" würde ich dieses Einhängen dann nicht nennen, sondern allenfalls "temporär".

Eine Möglichkeit zum wirklich "dynamischen" Mounten (d.h. automatisch bei Bedarf) ohne GVFS bietet AutoFS. Da musst Du Dich dann aber etwas einlesen, das ist ein bisschen komplizierter.

Gruß – Max-Ulrich

Hallo

der letzte Thread Beitrag ist schon 'ne Weile her. Da ich aber bei dem genannten Problem hier gelandet bin, hier kurz eine Lösung, die bei mir geholfen hat:

Auf einem frisch installierten Ubuntu 16.04 mit Libre Office Version: 5.1.4.2 Build-ID: 1:5.1.4-0ubuntu1 habe ich genau das gleiche Problem festgestellt. Ich habe meine Dokumente normalerweise auf einem NAS im lokalen Netzwerk eingebunden mit autofs. Das ist dann aktiv, wenn ich dort was schreiben möchte. Ansonsten ist das Teil aber aus. Jetzt wollte ich lokal etwas mit Libre Office Writer erstellen. Das lief eine Weile recht gut, dann bremste sich das System aus, so dass nur noch alle 30 Sekunden ein Buchstabe eingegeben werden konnte. Ich habe nachgesehen, das System ist nicht ausgelastet und es hängt auch kein Prozess (jedenfalls nichts gefunden). Mir fiel aber auf, dass Libre Office im Sekundentakt Netzwerk Resourcen benötigt. Und das war es auch. Es merkt sich wohl (dämlicherweise) alle seither angebundenen Resourcen und will auf die zugreifen obwohl der gerade laufende Job nichts damit zu tun hat. Schalte ich nämlich das NAS ein, kann ich mit Libre Office arbeiten wie normal.

Das war in den alten Libre Office Versionen, die ich davor hatte, nicht. Da konnte man mit arbeiten auch wenn solche Resourcen aus und nicht erreichbar waren. Ich verstehe nicht wie man sowas programmieren kann. Denn unterwegs mit dem Notebook ist das ja eine Katastrophe, wenn die Zuhause angebundenen Resourcen fehlen.

Hoffe, das hilft weiter.

Viele Grüße Sigi

Sry ich habe einen Fehler gemacht, ggf löschen 😳