staging.inyokaproject.org

Den von Peter.S angeblich entdeckten Eintrag in /etc/mtab kann ich nicht finden, weder in Ubuntu 14.04 noch in Ubuntu 16.04. Ich vermute, dass es sich dabei um eine Verwechslung handelt, möglicherweise mit dem cifs-vfs (?). Selbstredend funktioniert dann das von Aushängen mit sudo umount ... auch nicht.

Meines Erachtens kann es einen entsprechenden Eintrag in /etc/mtab gar nicht geben, weil das Einbinden hier im Userspace und damit nicht systemweit erfolgt.

Ich habe die entsprechenden Hinweise im Artikel deshalb vorerst auskommentiert.

Gruß – Max-Ulrich

Das folgende Script zeigt, daß sda7 zunächst nicht gelistet ist, aber nach Anwendung von gvfs-mount gezeigt wird:

Peter

------------------------------------------------------
Script started on Die 20 Sep 2016 22:28:43 CEST
^[]0;peter@RED: ~^Gpeter@RED:~$ mount
/dev/sda12 on / type ext2 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
/dev/sda3 on /c: type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096)
/dev/sda10 on /home type ext4 (rw)
/dev/sda9 on /usr/local type ext2 (rw,nosuid,nodev)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
gvfsd-fuse on /run/user/1001/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=peter)

^[]0;peter@RED: ~^Gpeter@RED:~$ gvfs-mount -d /dev/sda7
Mounted /dev/sda7 at /media/peter/a39c5886-0f09-402c-861e-099084c49bd7

^[]0;peter@RED: ~^Gpeter@RED:~$ mount
/dev/sda12 on / type ext2 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
/dev/sda3 on /c: type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096)
/dev/sda10 on /home type ext4 (rw)
/dev/sda9 on /usr/local type ext2 (rw,nosuid,nodev)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
gvfsd-fuse on /run/user/1001/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=peter)
/dev/sda7 on /media/peter/a39c5886-0f09-402c-861e-099084c49bd7 type ext2 (rw,nosuid,nodev,uhelper=udisks2)
^[]0;peter@RED: ~^Gpeter@RED:~$ exit

Script done on Die 20 Sep 2016 22:29:56 CEST
Script started on Die 20 Sep 2016 22:33:08 CEST
^[]0;peter@RED: ~^Gpeter@RED:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:        14.04
Codename:       trusty
^[]0;peter@RED: ~^Gpeter@RED:~$ exit

Script done on Die 20 Sep 2016 22:33:49 CEST
-----------------------------------------------------------------------------------

In der Tat, Peter.S hat zumindest zum Teil Recht. Sorry.

Allerdings muss man die Angelegenheit offenbar etwas differenzierter betrachten:

• Lokale Dateisysteme, die über das GVFS mit einem Mountpunkt in /media/<Benutzer> eingebunden werden, werden in /etc/mtab eingetragen und mit mount angezeigt.

• Netzwerk-Dateisysteme, die mittels GVFS direkt angesprochen werden (z.B. mit smb://... ), und für die nur über fuse noch ein alternativer Zugang in /run/user/1000/... eingerichtet wird, erscheinen micht in /etc/mtab und werden bei mount nicht mit angezeigt. Sie können auch nicht mit umount wieder ausgehängt werden.

Den ersten Fall (lokale Dateisysteme) hatte ich übersehen, da ich (wie wohl die meisten) das GVFS eben zum Einbinden von Netzwerk-Freigaben verwende.

Ich werde das noch einmal überprüfen und dann einen differenzierten Eintrag ins Wiki vornehmen.

Auf jeden Fall danke ich Peter.S dafür, dass er auf das Problem hingewiesen hat.

Gruß – Max-Ulrich

Danke für die Klärung der Zusammenhänge.

Noch eine kleine Bemerkung ad "wie wohl die meisten": Ich denke, es sind nicht so wenig, die Ubuntu auf einem alleinstehenden PC (Notebook, Laptop) installiert haben und sich nur selten oder nie in einem Netzwerk bewegen, aber gvfs-mount zum Einhängen einer anderen Partition (z.B., bei Dual-Boot) oder USB-Sticks verwenden – (explizit oder) zumindest implizit durch Anklicken in der Liste.

Grüße, Peter

Verbesserten Eintrag im Wiki vorgenommen.

Gruß – Max-Ulrich

Das GVFS ist noch immer für Überraschungen gut 😲

Durch den Thread im Forum "Ubuntu Samba Share, User kann root Dateien übernehmen" wurde ich auf ein Problem aufmerhsam, das ich sogar als Sicherheitsrisiko einstufen würde. Der Vorgang ist folgender:

1. Ich gebe den Ordner Test, dessen Eigentümer ich bin, mittels net usershare (bzw. durch klick…klick im Dateimanager) mit Schreibrechten, aber ohne Gast-Zugang frei.

2. Ich lege nun auf dem Server innrhalb dieses Ordners Test eine Datei Test/Tdatei an und mache diese mit sudo chown root:root Test/TDatei zum Eigentum von "Root". Wegen umask = 002 (Standard) haben nur Root und die Gruppe Root das Recht, die Datei Tdatei zu editieren und zu verändern.

3. Ich greife nun als gewöhnlicher User von einem Linux-Client aus über das GVFS bzw. direkt über den Dateimanager nach Eingabe von Benutzername und Samba-Passwort auf die Freigabe Test zu und editiere dort die Datei Test/Tdatei z.B. in gedit als gewöhnlicher Benutzer.

4. Nun der erste Hammer: Ich kann die Datei Test/Tdatei als gewöhnlicher Benutzer verändern und zurückspeichern, obwohl nach den UNIX-Dateirechten des Servers nur Root dazu berechtigt wäre! ❗

5. Und jetzt kommt's noch dicker: Untersuche ich nun anschließend mittels ls -la Test auf dem Server die Freigabe und die enthaltene Datei, so stelle ich fest, dass die Datei Test/Tdatei nun nicht mehr Eigentum von root:root ist, sondern dass sie durch den (IMHO unerlaubten) Schreibzugriff mittels GVFS/smb nun sogar zu meinem Eigentum geworden ist! ❗ ❗

Dieses überraschende, irritierende und IMHO absolut unzulässige Verhalten tritt ausschließlich bei der Kombination net usershare ("Persönliche Freigabe") auf dem Server und gvfs-mount auf dem Client auf. Bei "Allgemeinen Freigaben", die durch Eintrag in smb.conf eingerichtet wurden, respektiert das GVFS hingegen die UNIX-Dateirechte des Servers und lässt diese auch unverändert. Werden über net-usershare eingerichtete "Persönliche Freigaben" auf dem Client nicht über das GVFS, sondern mit dem cifs-vfs eingebunden, dann tritt das Problem ebenfalls nicht auf; die UNIX-Dateirechte des Servers werden respektiert und bleiben unverändert. Dasselbe gilt auch beim Zugriff von einem Windows-Client aus.

Der Verdacht, es könnte sich vielleicht um eine Überlagerung der UNIX-Dateirechte durch ACLs handeln, konnte durch getfacl Test/Tdatei auf dem Server ausgeräumt werden. ACLs waren vorher und nachher nicht gesetzt. Ich bin auch nicht in der smb.conf auf dem Server als admin user eingetragen.

Das beschriebene Problem ist beliebig nachvollziehbar. Da ich es mir überhaupt nicht erklären kann, bitte ich darum, den Sachverhalt weiter zu untersuchen und neue Beobachtungen hier mitzuteilen. Ich werde dann nötigenfalls eine Fehlermeldung verfassen und einen Hinweis im Wiki anbringen. Die Tatsache, dass GVFS/smb offenbar Dateirechte missachtet und diese sogar unzulässig verändert, finde ich gravierend!

Mit freundlichem Gruß – Max-Ulrich

Moin.

betrifft folgendes im Wiki:

@Hans9876543210

Du hast völlig Recht, Samba ist kein Netzwerk-Protokoll, sondern ein Netzwerk-Dienst für die Protokolle cifs bzw. smb1,2,3 …

Doch hier gibt es ein Problem: Mit cifs wird leider oftmals auch verkürzt das cifs-vfs bezeichnet, ein virtuelles Dateisystem (VFS) in UNIX/Linux speziell für Windows- und Samba-Freigaben. Und das GVFS unterscheidet sich beim Einbinden solcher Freigaben grundsätzlich vom cifs-vfs, und es unterstützt eben nicht dessen Optionen-Vielfallt. Die Aussage "Das GVFS unterstützt das Netzwerk-Protokoll cifs" wäre deshalb gerade für Anfänger, die die Feinheiten der Terminologie nicht kennen, missverständlich. Auch wenn wir im Wiki für das VFS möglichst konsequent die vollständige Bezeichnung "cifs-vfs" verwendet haben, zeigen Beiträge im Forum immer wieder, dass sehr viele Anwender "cifs" mit "cifs-vfs" identifizieren. Und dann wird dieses eben vom GVFS nicht unterstützt.

Microsoft selbst hat noch seinen Teil zur Begriffsverwirrung beigetragen, indem es zunächst die Bezeichnung "smb" für das Protokoll abgeschafft, diese dann aber später bei smb2 wieder eingeführt hat. Zwischendrin hieß das Protokoll auch bei Microsoft nur noch cifs. In Linux hatte man während dieser Zeit schon vieles umbenannt, was den Namen "smb" trug. Unabhängig von den Namens-Metamorphosen blieb nur die Bezeichnung des Dienstes "Samba" immer gleich.

Ich überlege gerade, wie man das Protokoll hier einerseits korrekt und andererseits aber auch unmissverständlich bezeichnen könnte.

Gruß – Max-Ulrich

Hallo,

vielleicht nur auf smb reduzieren und dann auf die offizielle Doku verweisen?

Da steht mittlerweile auch NFS als Backend. Hoffentlich schaffe ich es am Wochenende mal die gvfs Unterstützung für NFS zu testen.

gvfs-mount gibt es eigentlich nicht mehr. Deshalb darf es auch nicht mehr Titel des Wiki-Artikels sein. Mittels man gvfs-mount erhält man schon seit Ubuntu 18.04 nur noch folgende Aussage:

      gvfs-mount has been deprecated and it is redirected to gio mount.

Auch wenn die Syntax von gio mount weitgehend mit der des ehemaligen gvfs-mount übereinstimmt, besteht hier doch dringender Handlungsbedarf!

Eine umfassende Darstellung der gio-Kommandos wäre sinnvoll. Aber dies ist ein Unterfangen, das meine Möglichkeiten und Kenntnisse übersteigt. Aber den obsoleten Artikel gvfs-mount einfach auf sich beruhen lassen, bis er dann irgendwann im Archiv landet, geht auch nicht. Denn mittels Dateimanager arbeitet so gut wie jeder ständig mit gio-Kommandos. Mein Vorschlag ist:

• "Große Lösung": Am besten wäre, wenn sich hier jemand Kompetentes bereit erklären würde, das Thema gio-Kommandos umfassend und gleichzeitig für die "Allgemeinheit" verständlich darzustellen. Dann könnte der Artikel gvfs-mount ins Archiv wandern und durch eine Weiterleitung auf den neuen Artikel gio-Kommandos ersetzt werden.

• "Kleine Lösung": Alternativ könnte ich den bisherigen Artikel gvfs-mount aktualisieren. Er müsste dann in gio mount umbenannt werden und würde notwendigerweise im Vergleich zur "großen Lösung" mehr an der Oberfläche bleiben. Die Weiterleitung von gvfs-mount wäre genau so nötig. Diese "kleine Lösung" würde ich mir zutrauen, die "große Lösung" aber nicht.

Wenn sich niemand für die große Lösung bereit findet, dann sollte man die kleine Lösung wenigstens bald als Interim in Angriff nehmen. Dafür wäre eine Baustelle angebracht.

Gruß – Max-Ulrich

Hallo,

wir warten mal ein paar Tage, sonst gehen wir den Weg der "kleinen" Lösung ☺

Gruß, noisefloor

Hallo,

habe gerade mal ein bisschen gelesen: die kleine Lösung mit ein paar praktischen Beispielen reicht. GIO ist ja die I/O API zur Glib - und wer das vollumfänglich nutzen will muss sich so gut auskennen, dass er das Wiki hier (wahrscheinlich) gar nicht braucht. Die Untiefen von GIO sind IMHO nix für "normale" Desktopnutzer, von daher muss IMHO der Wikiartikel auch nicht in die Untiefen von GIO absteigen.

IMHO wäre es geschickter, den GIO Artikel _neu_ zu erstellen, damit man den frisch schreiben und nicht Gefahr läuft, Altlasten des bestehenden gvfs-mount Artikels umformuliert mit zu schleifen.

@Max-Ulrich_Farber: die Einleitung würde ich schreiben, wenn du dann die praktische Nutzung von gio bei steuerst ☺

Gruß, noisefloor

@noisefloor: Gerne! Ich hoffe, dass ich das dann auch ordentlich kann.

Damit wir uns richtig verstehen: Es gibt das GIO als I/O API zur Glib, und es gibt die Kommandozeilen-Befehle gio ..., also z.B. eben gio mount, gio copy, gio list usw. Vom ersten verstehe ich nichts; ich programmiere ja keine applications. Ich kann also nur zum zweiten etwas beitragen. Doch darum dürfte es hier ja auch gehen.

Also abgemacht, die "Theorie" machst Du, und ich sehe, was ich dann dazu praktisch hinkriege.

Beste Grüße
Max-Ulrich

Mit dem Artikel Baustelle/gio bin ich jetzt so weit, dass es sinnvoll ist, mit dem Artikel gvfs-mount parallel dazu weiterzuarbeiten. Deshalb bitte ich, diesen in die Baustelle zu verschieben.

Später soll der Artikel dann gio mount (ohne Bindestrich) heißen, da gvfs-mount deprecated ist. Es sollte dann ein Redirect von gvfs-mount auf diesen Artikel geben, genau so wie beim Programm selbst.

Gruß – Max-Ulrich

Hallo,

der Artikel hier ist doch "nur" für Xenial gültig - gibt's da gvfs-mount noch?

Wenn ja kann dieser Artikel gerne nur für Xenial gültig bleiben, weil der gio Artikel ja für Bionic, Focal & Co relevant ist und dieser Artikel hier kommt dann im April 2021 ins Archiv.

Also du kannst ihn natürlich trotzdem gerne überarbeiten wenn das nötig ist.

Gruß, noisefloor