NTFS automount unter Gnome3

ich stolpere gerade wieder über die Thematik NTFS, weil ich es inzwischen als DAS Austausch-Dateisystem für meine größeren USB-Sticks benutze und endlich auch mal in FreeBSD dann Dateisysteme erzeugen möchte. Aus meinem Bauchgefühl heraus habe ich das bisher nie gemacht und alles immer von einem Windows formatiert, was ich mit NTFS haben wollte. Seit einigen Jahren habe ich keine Probleme mehr mit ntfs-3g auf unterschiedlichen Plattformen erlebt. Deshalb wagte ich nun diesen Schritt und bin noch am probieren.

Was ich schon mal direkt sagen möchte: nachdem ich mit einem
chmod +s /usr/local/bin/ntfs-3g
mal testen wollte, ob danach mein User mounten kann, erhielt ich diese Meldung:
Code:
pit@senyo ~:- > ntfs-3g -o rw /dev/da1s1 /mnt/usb1
Mount is denied because setuid and setgid root ntfs-3g is insecure with the
external FUSE library. Either remove the setuid/setgid bit from the binary
or rebuild NTFS-3G with integrated FUSE support and make it setuid root.
Please see more information at
http://tuxera.com/community/ntfs-3g-faq/#unprivileged
Das sagt mir, dass grundsätzlich eine Möglichkeit bestehen könnte, dass dazu aber Eigenbau aus den Ports notwendig ist. Ich möchte das nicht. Daher lebe ich lieber damit, nicht als User zu mounten.

Inwiefern hat das etwas mit diesem Thema zu tun?
Ich will das teilen, denn automatischer Mount ist nicht ausreichend definiert und führte auch hier schon zu unterschiedlichen Interpretationen.

-1) automatisches Einbinden über einen Eintrag in der fstab (beim Booten)
-2) automatisches Mounten durch ein script oder einen Dienst zur Laufzeit

-1) der Eintrag in einer fstab führt dazu, dass ein "Root-Mount" beim Booten durchgeführt wird. Solche Einträge können sich nur auf ständig vorhandene Speichermedien beziehen. Diese müssen zur Bootzeit vorhanden sein, ansonsten kann das System hängen bleiben oder wenigstens den Start lange verzögern.
Die Option "noauto" kann ein automatisches Einbinden zur Bootzeit verhindern. Der Eintrag in der fstab stellt dann eine Abkürzung für einen manuellen Mount dar, den Root später ausführen kann.

-2) es gibt viele Möglichkeiten, weshalb hier genauer auf den Einzelfall geschaut werden müsste. Generell kann man vielleicht sagen, dass ein Programm oder Dienst die Mount-Funktion automatisch aufrufen muss und dass solch ein Dienst maximal aus User begriffen werden kann. Das bedeutet, solange das unveränderte ntfs-3g aus den Paketen benutzt wird, dürfe kein Weg möglich sein, dass irgendein Dienst diesen Mount erfolgreich initiieren könnte. Um Nachforschungen anzustellen, müsste man sich ansehen, ob der entsprechende Dienst ein Gerät richtig erkennt und dann einen Mount-Aufruf generiert, der überhaupt passt. Ist dies der Fall, könnte man vielleicht darüber nachdenken, diesen Dienst mit höheren Rechten auszustatten, ihn quasi als Root laufen zu lassen. Ich würde das nicht machen, aber es wäre vielleicht eine Möglichkeit.
Die Analyse ist nicht sehr kompliziert, aber sehr zeitintensiv, besonders dann, wenn HAL benutzt wird. Es gibt aber Monitorringfunktionen, um dem Geschehen auf den grund zu gehen. lshal ist nur der Anfang, um zu sehen, was da erkannt wird. Ich will das aber hier nicht weiter führen.

Es erscheint mir eben nach Verlauf dieses Threads sehr wichtig, dass wir genauer hinsehen, worüber wir eigentlich reden wollen. Automount ist offenbar nicht eindeutig genug.

Außerdem wiederhole ich nochmal den Rat, in die ausgezeichneten Wiki's bei Ubuntu oder Arch zu sehen, etwa:
https://wiki.archlinux.org/index.php/NTFS-3G
 
Ohne das jetzt probiert zu haben, brauchst Du eventuell einfach das sysctl vfs.usermount auf 1 setzen. Zumindest ist das für fuse-sshfs der Fall.
 
Ohne das jetzt probiert zu haben, brauchst Du eventuell einfach das sysctl vfs.usermount auf 1 setzen. Zumindest ist das für fuse-sshfs der Fall.
Code:
pit@senyo ~:- > sysctl vfs.usermount
vfs.usermount: 1
Bei mir ist das der Fall und es funktioniert bei einigen anderen Dateisystemen. Es funktioniert nicht bei ntfs-3g und simple-mtpfs und für beide habe ich auch immer nur von Root.Mounts im Zusammenhang mit FreeBSD gelesen und beide sind FUSE-Applikationen. Es funktioniert wiederum (mit den gegebenen Einschränkungen) mit ext4fuse.
 
Danke @cabriofahrer , du hast mich verstanden :)

Es scheint tatsächlich eine schwierige Angelegenheit zu sein und/oder einfach kaum gefragt unter den sicherheitsbewussten BSDlern so dass man es austüfteln muss.

Werde mir nochmal TrueOS ansehen da es dort mit dem Automount von NTFS klappt wenn man einen USB-Stick einsteckt. Ich kann mich aber erinnern dass sie in die fstab nichts gepackt hatten was mit NTFS-3G zusammenhängt.


LG Lance
 
Es scheint tatsächlich eine schwierige Angelegenheit zu sein und/oder einfach kaum gefragt unter den sicherheitsbewussten BSDlern so dass man es austüfteln muss.
@Lance heute Morgen habe ich überlegt, mal einen Thread zu starten mit dem Titel: Device-Manager von KDE / Gnome / xfce unter FreeBSD
Denn das sollte doch zu lösen sein. Unter plasma5 funktioniert es übrigens bei mir nicht mit einer USB-Platte, die mit fat32 formatiert ist. Und was ich bisher dazu gefunden habe, fiunktioniert auch nicht bei mir, weil es vermutlich veraltet ist.

Werde mir nochmal TrueOS ansehen da es dort mit dem Automount von NTFS klappt wenn man einen USB-Stick einsteckt. Ich kann mich aber erinnern dass sie in die fstab nichts gepackt hatten was mit NTFS-3G zusammenhängt.
OT: Ich möchte das System nicht schlecht reden, habe es mir erst vor wenigen Tagen auf mein Notebook installiert - und war unter dem Strich ziemlich enttäuscht. Mittlerweile läuft dort wieder ein FreeBSD mit selbst gebautem plasma5. Falls Du Interesse an Details meiner TrueOS-Erfahrungen hast, gerne per PN, denn das sprengt hier das Thread-Thema.
 
Ich kann mich aber erinnern dass sie in die fstab nichts gepackt hatten was mit NTFS-3G zusammenhängt.
Also, vielleicht nochmal, um nicht irgendwie Missverständnisse zurück zu lassen.
Die /etc/fstab wird beim Booten ausgewertet und entsprechende Aktionen durchgeführt. Ein Gerät (besser Speichermedium, es kann auch eine Freigabe im Netz sein), das hier eingetragen ist, muss also zur Bootzeit auch vorhanden sein. Nachdem das System gestartet ist, wird die fstab ohne weiteres nicht mehr berücksichtigt, sie wird nicht mehr abgearbeitet und ist deshalb nicht am automatischen Mounten von Wechselmedien beteiligt.

Was man machen kann, will ich am Beispiel CDROM beschreiben. Siehe auch die man fstab, etwa hier: https://www.freebsd.org/cgi/man.cgi...FreeBSD+11.0-RELEASE&arch=default&format=html
Wenn die fstab einen solchen Eintrag enthält:
Code:
     # CDROM.  "noauto"	option is typically used because the
     # media is	removable.
     /dev/cd0	     /cdrom	     cd9660  ro,noauto	     0	     0
, dann wird nicht automatisch zur Bootzeit gemountet, aber der Eintrag in der fstab ist vorhanden und wird vom System berücksichtigt. Nun kann mit einem einfachen mount /cdrom eine CD zur Laufzeit eingebunden werden, weil die Einträge aus der fstab ausgewertet werden. Siehe dazu man mount, etwa: https://www.freebsd.org/cgi/man.cgi...FreeBSD+11.0-RELEASE&arch=default&format=html
If either special or node are not provided, the
appropriate information is taken from the fstab(5) file.
Ich zeige das mal bei mir, den Eintrag aus der fstab und das einfache mounten einer eingelegten DVD (KNOPPIX):
Code:
/dev/cd0	/mnt/cdrom	        cd9660	 ro,noauto	0	0

pit@senyo ~:- > mount /mnt/cdrom
pit@senyo ~:- > ls /mnt/cdrom
autorun.bat	autorun.inf	autorun.pif	boot		cdrom.ico	efi		index.html	KNOPPIX
pit@senyo ~:- > umount /mnt/cdrom
pit@senyo ~:- > ls /mnt/cdrom
pit@senyo ~:- >
Das gelingt nur, weil /dev/cd0 in der fstab zugeordnet wurde und weil /dev/cd0 vorhanden ist. Der Eintrag noauto sorgt dafür, dass der Bootvorgang nicht hängen bleibt, weil kein Medium eingelegt ist.
Auf diese Weise kann man externe Datenträger behandeln, auch dann, wenn sie NTFS haben. Aber, ob die Zuordnung der Geräte passt, dafür muss man dann selbst sorgen und ntfs-3g unter FreeBSD wird immer noch nicht von einem normalen User ausführbar sein.
Selbstredend ist dies kein Automatismus, der beliebige Wechselmedien behandeln kann.
Das taugt nur für wohlbekannte Datenträger mit stets gleichen Bedingungen.
Der Mount-Befehl muss immer noch manuell abgesetzt werden und deshalb habe ich das oben als eine Abkürzung bezeichnet. Man muss nicht alles eintippen, es genügt eine Kurzform.
Den gleichen Effekt kann man mit einem eigenen Kurz-Script erreichen. Hier können dann sogar weitere Eigenschaften ausgewertet und etwa wohlbekannte Datenträger nach ihren Eigenschaften immer wieder gleich eingebunden werden.
All dies, was ich da nun beschrieben habe, kann man als Automatisierungen beim Mounten bezeichnen, aber ich persönlich verstehe unter einem automatischen Mount das Einbinden beliebiger Wechseldatenträger durch einen Dienst oder mehrere Dienste.
Es ist in dem Zusammenhang dann interessant, ob ein normaler User einen Mount durchführen darf, weil diese Dienste ja in aller Regel niemals Root-Rechte erhalten sollen.

Die bekannten Mechanismen setzen auf Hal und weitere Dienste. Ich habe mal hal bei mir gestartet (normalerweise läuft der nicht) und einen USB-Stick eingesteckt. lshal -m zeigt dann eine Aktion:
Code:
pit@senyo ~:- > lshal -m

Start monitoring devicelist:
-------------------------------------------------
10:01:54.785: usb_device_951_1666_08606E6D407FBF1087180A31 added
10:01:54.883: usb_device_951_1666_08606E6D407FBF1087180A31_if0 added
10:01:54.889: usb_device_951_1666_08606E6D407FBF1087180A31_if0_scsi_host added
10:01:54.891: usb_device_951_1666_08606E6D407FBF1087180A31_if0_scsi_host_scsi_device_lun0 added
10:01:56.517: storage_serial_08606E6D407FBF1087180A31 added
10:01:56.519: storage_serial_08606E6D407FBF1087180A31 property storage.removable.media_available = true (new)
10:01:56.520: storage_serial_08606E6D407FBF1087180A31 property storage.removable.media_size = 62075699200 (0xe74000000) (new)
10:01:56.522: storage_serial_08606E6D407FBF1087180A31 property info.interfaces = {'org.freedesktop.Hal.Device.Storage.Removable'} (new)
10:01:56.623: volume_part2_size_62027874304 added
10:01:56.734: volume_uuid_0915_24AE added
Wir können mit FreeBSD eine ganz ähnliche Information erhalten, wenn wir cat /var/run/devd.pipe ansehen/auswerten (ein Monitoring-Betrieb, es passiert nur dann etwas in der Ausgabe, wenn es etwas zu berichten gibt, also etwa ein Stick gesteckt wird). Es schreibt nur niemand einen Automounter für FreeBSD. Also nutzen wir Mechanismen, die aus anderen System kommen.
Die Information bekommt Hal vom dbus-Dämon (afaik), dieser muss also zwingen auch laufen, wenn Hal Erfolg haben soll. Hal erkennt zunächst nur, erst der Policity-Kit-Dämon (verzeiht mir falsche Schreibweise, das bringt mich jedes mal zum Stolpern) verknüpft Hal-Ereignisse mit Regeln, die wiederum in xml-Dateien beschrieben werden. Wir brauchen für FreeBSD andere Regeln, als andere Systeme, weil unsere Geräte ja anders heißen und einige weitere Abweichungen gelten. Eine schnelle Suche zeigt mir dies als Paket:
Code:
pit@senyo ~:- > pkg search policykit
policykit-0.9_10               Framework for controlling access to system-wide components
policykit-gnome-0.9.2_8        GNOME frontend to the PolicyKit framework
policykit-qt-0.9.4_1           PolicyKit manager for Qt
Nochmal (afaik):
es muss dbus, hal und der policikit jeweils als Dämon im Hintergrund laufen und dann müssen sie auch noch die passenden Regeln finden und umsetzen.

Man kann das alles mit hilfreichen Monitoring-Programmen durchsuchen und ansehen und Stellen finden, wo es vielleicht nicht funktioniert. Oft hängt es an Regel-Einträgen, die vielleicht einem User nicht das Mounten erlauben oä.
Mann kann damit nicht erreichen, dass ein ntfs-3g Paket umgebaut wird. Wenn das FreeBSD ntfs-3g nicht für User-Mounts gemacht ist (und das sagt es einem ja), kann es nicht von diesem Automatismus benutzt werden.

Der Aufwand, Fehler aufzuspüren, kann zeitlich enorm sein. Die Korrektur kann einfach sein und wird vielleicht mit dem nächsten Update zurückgesetzt. Es ist extrem schwierig, etwas allgemeingültig zusammen zu bauen, das für alle möglichen Umstände Gültigkeit behalten soll.
Es ist super einfach, auf diesen Wust an Code-Zeilen zu verzichten und einfach manuell zu mounten. Ich fühle mich damit inzwischen sehr viel wohler und entspannter, so lange ich auf FreeBSD bin und nicht erst wieder für jeden neuen Vorgang verschiedene man-pages lesen muss. Deshalb wird es wahrscheinlich nicht sehr viele Interessierte geben, die an derartigen Tools ernsthaft arbeiten.
 
es geht mir soeben auf, dass ich das nicht deutlich sagte: der eigentliche mount wird ja nicht von einem der Dienste dbus, hal oder policykit durchgeführt. Die übergeben ihre gesammelte Weisheit an einen Dienst des DesktopEnvironemnts, das dann den mount durchführt oder einleitet. Also, auch mit den drei gestarteten Diensten kann ich noch nicht erwarten, dass ein automatischer Mount mir in einem nicht weiter ausgebauten fluxbox gelingen wird.
pcmanfm, als guter Dateimanager und etwas mehr, bietet auch eine Option, Wechselmedien automatisch zu mounten. Wie das geht, weiß ich nicht, aber es zeigt, dass es hier auch Bemühungen abseits eines DE gibt.
Für einen Endanwender ist es furchtbar, alle diese Stränge zusammen zu führen und zu ordnen. zumal es nicht einen einzigen Platz für Dokumentation zu diesem Thema gibt, alles ist schrecklich unübersichtlich und ungeordnet.
 
Also wenn das hier mal einer hinbekommt, so dass es wie bei den Linux-Distris funktioniert dann möge er das bitte posten, es würde mich und sicher viele andere sehr freuen! :)

LG Lance


Hallo Lance, hallo zusammen,

das hier ist mein erster Beitrag, und ich fühle mich etwas schäbig, hier in gewisser Weise Eigenwerbung zu machen.

seit Jahren benutze ich sysutils/dsbmd mit sysutils/dsbmc. Damit kann man die gängigen Dateisysteme, inklusive NTFS, per Mausklick ein- und aushängen. Unabhängig davon, ob man eine DE oder einen WM, oder welchen Dateimanager man benutzt. Die Standardkonfiguration erfordert für meinen Bedarf keine Anpassung. Möchte man die Speichermedien ohne zu klicken einhängen, kann man auch dsbmc-cli als Automounter/unmounter starten.

Beste Grüße
Marcel
 
Hallo Holger,

ich bin Maintainer und Entwickler.

Diese Art von Eigenwerbung dürfte hier wohl ausgesprochen willkommen sein :)

Ich finde es immer gut, wenn auch Entwickler zu ihren Sachen in Foren etwas schreiben, denn das ist immer eine Hilfe aus erster Hand, und ihr kennt Euer Zeugs doch am besten :D

Deine Software werde ich gerne mal ausprobieren, danke.

Viele Grüße,
Holger
 
Diese Art von Eigenwerbung dürfte hier wohl ausgesprochen willkommen sein :)

Ich finde es immer gut, wenn auch Entwickler zu ihren Sachen in Foren etwas schreiben, denn das ist immer eine Hilfe aus erster Hand, und ihr kennt Euer Zeugs doch am besten :D

Deine Software werde ich gerne mal ausprobieren, danke.

Das freut mich zu lesen :).
 
hier in gewisser Weise Eigenwerbung zu machen
wie lange benutze ich nun schon FreeBSD? Vielleicht knappe zehn Jahre. ich mache das nicht beruflich und nicht als Hobby, sondern als Endanwender, der gerne OpenSource nutzen möchte. jedenfalls habe ich zuvor noch nie von deinen ports gehört.
Also funktioniert die allgemeine oder Fremd-Werbung ganz offensichtlich nicht.

Deshalb bin ich für derartige Eigenwerbung extrem dankbar, weiter so!!!
 
Hallo Lance, hallo zusammen,

das hier ist mein erster Beitrag, und ich fühle mich etwas schäbig, hier in gewisser Weise Eigenwerbung zu machen.

seit Jahren benutze ich sysutils/dsbmd mit sysutils/dsbmc. Damit kann man die gängigen Dateisysteme, inklusive NTFS, per Mausklick ein- und aushängen. Unabhängig davon, ob man eine DE oder einen WM, oder welchen Dateimanager man benutzt. Die Standardkonfiguration erfordert für meinen Bedarf keine Anpassung. Möchte man die Speichermedien ohne zu klicken einhängen, kann man auch dsbmc-cli als Automounter/unmounter starten.

Beste Grüße
Marcel

Hi Marcel,
mein Unterkiefer war vor Staunen fast am Boden und ich hatte sogleich ein Schmunzeln als ich pit234a´s Antwort gelesen hatte. Danke sehr für deinen Post, finde ich super! Immer her mit der Eigenwerbung, ich freu mich, es auszuprobieren!! :)
 
@marcel
wenn wir dich schon mal hier haben und ich denke, das ist nicht den Rahmen des Threads gesprengt: kannst du uns ein wenig dazu erklären?

Ich lese, dass du das device-System benutzt. Das ist schon mal FreeBSD-vernünftig, wo wir doch hier viel besser funktionieren, als im Linux-Lager.
Hast du einen eigenen Dienst, der das anschaut? Benutzt du andere Dienste im System dafür? Du brauchst also keinen Hal und keinen dbus und so weiter.
Wie machst du das, dass ntfs-3g benutzt wird und User damit sogar rw mounten können?
Du machst das auch mit simple-mtpfs, wie ich lese.
Wie funktioniert das in Zusammenarbeit mit einem WM? Also, vermutlich ist der Dateimanager hier verantwortlich? denn wer sollte sonst ein icon anbieten, das geklickt werden kann?
Ich habe im Augenblick keine große Lust, mich damit zu befassen. ich verstehe aber auch, wenn jemand keine große Lust (oder Zeit) hat, mir meine Fragen einfach zu beantworten, anstatt dass ich selbst damit arbeite und was heraus finde.
Fragen kostet nichts...
 
Erkläre das mal bitte genauer. Ich kann mit dieser Aussage nichts anfangen. Was ist besser als im Linux-Lager?
im Linux gab es Ärger mit devd und deshalb wurde ja letztlich auf Hal gesetzt. Schließlich wurde das alles durch udevd ersetzt oder ergänzt. Und gerade spricht man von systemd, das nicht nur zum Starten von Systemdiensten benutzt werden soll, sondern quasi die nächste Verbesserung auch für das Device-System in Aussicht stellt. Im Gegenzug dazu ist bei FreeBSD niemals solcher Ärger im device-System entstanden, es brauchte keinen Hal und kein Udevd, um irgendwas zu verbessern. Es konnte einfach bei devd bleiben, weil das nie verhunzt worden ist. Mir gefällt das schon mal. Wichtig ist aber, dass man im Linux-Lager nicht ganz unerhebliche Anstrengungen unternommen hat, um die Probleme zu umschiffen. Viele Anwendungen zogen mit, denken wir an X, das plötzlich Hal brauchte und so zogen manche dieser Linux-Notwendigkeiten durch die Hintertür auch bei FreeBSD, bzw der ebenfalls benutzten Thirdparty-SW mit ein. Die hier weiter oben besprochenen Automount-Mechanismen mit Hal und so weiter sind ein Beispiel für eine solche Lösung, die aus dem Linux-Lager gekommen ist.
Für FreeBSD hätten wir das nie gebraucht. Es konnte sich immer gut auf das eigentlich verantwortliche devd verlassen.
Deshalb gefällt es mir natürlich, wenn Anwendungen hier nicht die Mechanismen für Linux voraussetzen, sondern direkt zu den Informationen aus FreeBSD greifen. Wir haben die ja.
Das halte ich für vernünftig und für besser, als im Linux-Lager (wobei ich überhaupt keine Blockbildung möchte oder gegen Linux anmotzen will).
 
Für FreeBSD hätten wir das nie gebraucht. Es konnte sich immer gut auf das eigentlich verantwortliche devd verlassen.
Deshalb gefällt es mir natürlich, wenn Anwendungen hier nicht die Mechanismen für Linux voraussetzen, sondern direkt zu den Informationen aus FreeBSD greifen. Wir haben die ja.

Warum hat der User Lance dann Probleme mit "NTFS automount unter Gnome3". Irgendwie kapier ich das nicht! Wo klemmt die Säge?

User Lance sagt unter "Linuxdistris" würde es funktionieren.
 
Warum hat der User Lance dann Probleme mit "NTFS automount unter Gnome3". Irgendwie kapier ich das nicht! Wo klemmt die Säge?

User Lance sagt unter "Linuxdistris" würde es funktionieren.
Das ist eben genau kein Widerspruch.
Es ist zunächst auch unter Linux gar nicht so einfach, aber dafür wurden die Automatismen ja gemacht. Für FreeBSD müssen die erst "übersetzt" und angepasst werden. FreeBSD hat die "Linux-Umwege" ja nicht und deshalb funktioniert die Übersetzung bei uns nicht so ganz trivial, allerdings nur auf die Automatismen bezogen.
Diese Automatismen werden in Linux von den Distributoren vorbereitet und eingebaut und deshalb hat der Endanwender dann keine Probleme damit.
Sie gehören auch im Linux nicht direkt zum Grundsystem, haben nichts direkt mit GNU/Linux zu tun.
Sie sind auch in FreeBSD nicht enthalten. Sie sind Zusatz-SW.

Warum es bei manchen Anwendern (angeblich) funktioniert und bei anderen nicht, können wir nicht pauschal erörtern. Ich kann nur von den schlimmen alten Zeiten reden und da funktionierte es bei mir sehr gut mit FreeBSD und mit KDE3 und Hal, dbus und polkit und einigen Einträgen in diversen Dateien, zumindest mit FAT. Es ist nicht so, als könne das grundsätzlich nicht mit FreeBSD und den umgebauten Linux-Mechanismen funktionieren. Es erfordert nur sehr viel Mühe und genaues Hinsehen, um evtle Fehler zu finden. Sie können überall lauern.

Die Tools von marcel verzichten offenbar auf "Umwege über Linux-Mechanismen" und nehmen direkt auf FreeBSD und dessen Innenleben Bezug. Ich wusste nicht, dass es so etwas gibt, aber es ist ja genau das, was wir immer gerne haben wollten. Es ist nur nirgendwo eingebaut, wie es mir scheint.
 
Diese Automatismen werden in Linux von den Distributoren vorbereitet und eingebaut und deshalb hat der Endanwender dann keine Probleme damit.

Wenn Gnome3 nur auf Linux aufgerichtet ist/wird, ich kann das nicht beurteilen, hat FreeBSD ein Problem. Gnome3 wird dann nicht die von Linux abweichenden BS-Mechanismen in den BSD Familien integrieren und es diesen überlassen die hier geschilderten Probleme zu lösen. Sehe ich das falsch?
 
@marcel
wenn wir dich schon mal hier haben und ich denke, das ist nicht den Rahmen des Threads gesprengt: kannst du uns ein wenig dazu erklären?

Ich lese, dass du das device-System benutzt. Das ist schon mal FreeBSD-vernünftig, wo wir doch hier viel besser funktionieren, als im Linux-Lager.
Hast du einen eigenen Dienst, der das anschaut? Benutzt du andere Dienste im System dafür? Du brauchst also keinen Hal und keinen dbus und so weiter.
Wie machst du das, dass ntfs-3g benutzt wird und User damit sogar rw mounten können?
Du machst das auch mit simple-mtpfs, wie ich lese.
Wie funktioniert das in Zusammenarbeit mit einem WM? Also, vermutlich ist der Dateimanager hier verantwortlich? denn wer sollte sonst ein icon anbieten, das geklickt werden kann?
Ich habe im Augenblick keine große Lust, mich damit zu befassen. ich verstehe aber auch, wenn jemand keine große Lust (oder Zeit) hat, mir meine Fragen einfach zu beantworten, anstatt dass ich selbst damit arbeite und was heraus finde.
Fragen kostet nichts...

Hallo pit234a,

zum einen gibt es den Dienst dsbmd, der das Herzstück ist. Er schaut sich beim Start alle zu diesem Zeitpunkt existierenden Speichermedien an, und identifiziert die sich darauf installierten Dateisysteme, ermittelt die Art des Geräts, überprüft in regelmäßigen Abständen, ob sich die Medien in einem DVD-Laufwerk oder einem USB/MMC-Kartenleser geändert haben. Dasselbe gilt dann auch für Geräte, die später zur Laufzeit hinzukommen. Dazu lauscht dsbmd am devd-Socket. Darüber hinaus wird dann auch die Mount-Tabelle ständig überprüft, sodass Mounts/Unmounts, die nicht über dsbmd gehen, ebenfalls repräsentiert sind. Über ein einfaches Textprotokoll verständigt sich der Dienst mit Clients, die ihn z.B. zum Mounten eines Geräts auffordern, oder Informationen über dieselben einholen. Die Autorisierung läuft dabei über UNIX-Domain-Credentials. Per Standardeinstellung können sich alle Mitglieder der wheel-Gruppe mit dem Dienst verbinden. Sendet ein Client einen Mount-befehl, so legt dsbmd ein Unterverzeichnis unter /media als Mountpoint an, und macht dasselbe les- und schreibbar für den Client/User, der den Befehl initiiert hat. Dadurch kann er auf diesen bei den meisten Dateisystemen (außer UFS) lesend und schreibend zugreifen.

Zum anderen gibt es Clients. dsbmc etwa ist ein kleines GTK+-Programm, das im System-Tray läuft, und in einem Fenster die derzeit an System angeschlossenen Speichergeräte, die mountbar oder gemounted sind, als Icons zeigt (siehe Screenshots). Per Kontextmenü können dann gemäß des Typs Aktionen ausgeführt werden. Man kann auch veranlassen, dass DVDs oder Audio-CDs beim Einlegen automatisch abgespielt werden.

Dadurch besteht keinerlei Abhängigkeit davon, welchen Dateimanager oder welche/n DE/WM man benutzt.

Ich hoffe, meine Ausführungen waren hilfreich und nicht all zu wirr.

Beste Grüße
Marcel
 
@marcel
vielen Dank. Ich kann mir da schon was vorstellen.
In der Tat erinnere ich mich sogar an etwas, das rein äußerlich ganz deiner Beschreibung entspricht. Ich habe so etwas schon mal in einem System gesehen, vor vielen Jahren, wahrscheinlich noch vor dem Hal und so weiter. Vielleicht in einem Ghost-BSD? Ich weiß nicht mehr.

@Freigeist
Ich würde das natürlich anders sehen oder sagen. FreeBSD hat überhaupt kein Problem damit, was GNOME oder irgendein anderes DE so macht. FreeBSD interessiert sich nicht für GNOME und ähnliches.
Aber für uns Endanwender spielt es tatsächlich im Ergebnis die Rolle, die du erwähnst. Es kann für uns durchaus problematisch werden, wenn Anwendungen immer konzentrierter und immer enger an Linux angepasst entwickelt werden. Das ist ein Teil der leidigen Diskussion um systemd. Das wird so nicht FreeBSD kompatibel sein (und auch nicht mit vielen anderen Systemen). systemd ist als reines Linux-Kind geboren und zwar ganz erklärtermaßen (mit einer gewissen Arroganz, wie ich finde). Hal konnte damals Plattformübergreifend realisiert werden und hatte ja auch zu Anfang gerade die Idee, eine gewisse "Einheits-Schicht" zu schaffen, die für alle Systeme brauchbar sein sollte. Eine frühe Kritik an systemd war genau die befürchtete Folge für die anderen, kleineren OpenSource Projekte, wie eben FreeBSD, dass es immer weniger Programme geben könnte, die dann noch mit vertretbarem Aufwand kompatibel bleiben würden.
Es ist afaik im Augenblick nur ein DE direkt für FreeBSD in der Entwicklung, dieser CDE-Nachfahre, Lumina oder so. Alles andere hängt direkt an Linux.
Fast alle zusätzliche SW wird mit dem Schwerpunkt auf Linux entwickelt, woraus sich schon sehr oft Probleme für die Adaption an FreeBSD ergaben. Es gibt fast immer Lösungen, aber nicht immer sofort und manchmal nicht sehr schön.
Das sollten wir hier nicht vertiefen, aber es ist gar nicht so schlecht, sich das alles mal vor Augen zu führen und die vielen Grabenkämpfe, die wir einfachen Endanwender immer nur kopfschüttelnd wahrnehmen und gar nicht wirklich begreifen können, mal aus mehreren Blickwinkeln zu verfolgen. Da sind Lizenzen plötzlich nicht so unwichtig und Standards, wie sie Posix oder die FreeSW-Foundation fordern.

Was die Funktion selbst angeht, also diese Geräte-Erkennung und die Dienste, die es dazu braucht, um schließlich einen passenden mountbefehl zu erzeugen, die werden auch nicht von GNOME selbst entwickelt. GNOME oder KDE und so weiter, die nutzen das nur.
Die großen Linux-Distributionen sind vergleichsweise mächtig. Im Vergleich zum FreeBSD Team oder gar zu OpenBSD oder den anderen BSDs ist so etwas wie Ubuntu ein Gigant. Die großen Macher aus USA, also was früher Redhat war, die bestimmen oft große Richtungen in der Entwicklung vollkommen eigenmächtig.
Sie publizieren etwas und dann werden Lösungen gebaut und angenommen und verteilen sich. Innerhalb weniger Wochen war damals in allen Distributionen sehr plötzlich Hal aufgetaucht, später udev. Da laufen bei einigen erst die Diskussionen an, während andere schon vollendete Tatsachen vorstellen. Und das geht so weit, dass die größeren Distros auch die einzelnen Bauteile stark verändern, damit sie ins Konzept passen. Diese Veränderungen können schnell zurück fließen und werden dann manchmal Allgemeingut. Dabei denkt niemand an die Verträglichkeit zu FreeBSD. Erst die Maintainer der Ports bei FreeBSD haben dann die große Aufgabe, hier wieder was zu richten.
Die Entwicklungen bei Linux wirken auf mich oft sehr hektisch, als gäbe es einen ständigen Zwang zur Veränderung. Es macht auch einen eher unkoordinierten Eindruck.
Und als Endanwender, der nur einfach eine Distro her nimmt und aufspielt, merkt man davon eben nichts, weil nach außen das System immer rund erscheint und funktioniert.

Die einzelnen Projekte sind oft nicht anders. Gerade GNOME ist ein gutes Beispiel. Da kann es auch sein, dass adhoc eine Entscheidung kommt und eine neue Entwicklung in unerwarteter Richtung los läuft. Nicht selten spalten sich dann Zweige ab, weil nicht alle mit der neuen Richtung zufrieden sind (wie etwa MATE bei GNOME).

Also, da gibt es ganz ganz oft Entwicklungen, die uns als Endanwender und besonders mit FreeBSD nicht unbedingt glücklich machen.
 
Wenn Gnome3 nur auf Linux aufgerichtet ist/wird, ich kann das nicht beurteilen, hat FreeBSD ein Problem. Gnome3 wird dann nicht die von Linux abweichenden BS-Mechanismen in den BSD Familien integrieren und es diesen überlassen die hier geschilderten Probleme zu lösen. Sehe ich das falsch?
Gnome war schon immer, also wirklich seit den Anfängen, ein sehr liuxzentrischer Desktop und lief auf anderen Plattformen bestenfalls so lala. Das ist definitiv keine neue Entwicklung, sie wird durch systemd lediglich verschärft. Wobei Gnome und systemd auch gar nicht untrennbar eng zusammenhängen, wie gerne behauptet wird. Der FreeBSD-Port war entsprechend auch schon immer ein "Best Effort"-Ansatz, er lief mal besser und mal schlechter. Je nach dem, wie viel sich zwischen den jeweiligen Versionen geändert hat und wie groß das Interesse war. Im Moment scheint das Interesse an Gnome auf FreeBSD sehr überschaubar zu sein, wahrscheinlich durch Gnome 3. Ich habe Gnome 3 inzwischen zwar schätzen gelernt, es hat sich in meinen Augen gut entwickelt und ist angenehm zu bedienender, nicht allzu überladender Desktop geworden, aber das Ding ist durch sein doch sehr vom sozusagen Windows-Standard abweichendes Bedienkonzept nicht jedermanns Sache. Entsprechend hängt der FreeBSD-Port bei Gnome 3.18, während die aktuelle Version 3.24 wäre. Der Gnome 2 Fork Mate hingegen ist mit Version 1.18 aktuell.
 
Ich bekomme unter KDE4 die Fehlermeldung "Sie haben keine Berechtigung, sich mit DSBMD zu verbinden beim Start von DSBMC - als normaler Nutzer (Gruppe "staff")

LG Lance
 
Zurück
Oben