staging.inyokaproject.org

Wie ich sehe, hat kB in der Baustelle bereits am 21.1. einen Artikel NTFS3 mit dem Ziel 29.2. angelegt. Bisher enthält dieser etwas angepasste Passagen aus dem Artikel NTFS-3G und auch Abschnitte, die sich allgemein auf Windows-Dateisysteme, also auch auf FAT32/VFAT und exFAT beziehen.

Ich denke, das Ziel für die Fertigstellung ist sicher nicht mehr aktuell, wir müssen uns dafür deutlich mehr Zeit lassen.

Als nächstes wird wohl kB den Entwurf inhaltlich aufteilen in das, was allgemein Windows-Dateisysteme angeht und das, was speziell den Kernel-Treiber NTFS3 betrifft. Dann könnte zunächst mit dem Ziel einer Materialsammlung eine Diskussion für den Artikel NTFS3 gestartet werden, die diesen Thread entlasten kann, und in der eine Gegenüberstellung der Treiber NTFS-3G und NTFS3 ein wichtiges Thema sein wird.

Der erste, verschiedene Windows-Dateisysteme betreffende Teil wird in den Übersichtsartikel Windows-Partitionen einbinden einfließen (als Ziel ist auch 29.02. genannt), für den schon eine (sehr umfangreiche) Diskussion besteht. Doch ich gehe davon aus, dass kB diesen Artikel im wesentlichen allein bearbeiten wird und dass dafür deutlich mehr Zeit nötig ist.

Weil ich nicht weiß, wann der Artikel in die Baustelle kommt - das ist nicht drängelnd gemeint, ich weiß um das fehlende Engagement und das jeder auch einen Alltag zu meistern hat - lade ich meine Änderungen bezüglich des Einhängens hier schon mal ab:

SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ntfs", ENV{ID_FS_TYPE}="ntfs-3g"

blacklist ntfs3

udisksctl info -b /dev/sdXY | grep -E 'HintSystem|IdUUID' 

    HintSystem:                 true
    IdUUID:                     362F9B1C209845D1

# ==1: mount ist nur durch den Benutzer root (sudo) möglich
# ==0: mount ist auch für unprivilegierte Nutzer möglich
SUBSYSTEM=="block", ENV{ID_FS_UUID}=="362F9B1C209845D1", ENV{UDISKS_SYSTEM}="0"

sudo mount PARTITION MOUNTPUNKT
sudo mount -t ntfs PARTITION MOUNTPUNKT
sudo mount -t ntfs-3g PARTITION MOUNTPUNKT
sudo ntfs-3g PARTITION MOUNTPUNKT  

sudo mount -t ntfs UUID=58CC69AFCC6987D8 /media/Bilder  

udisksctl mount -b /dev/sdXY 

UUID=58CC69AFCC6987D8 /media/Bilder ntfs defaults 0 0

Max-Ulrich_Farber schrieb:

Jetzt wäre noch interessant herauszufinden, wie sich ein 22.04 verhält, welches durch Upgrade von 20.04 entstanden ist

Das haben wir ja schon untersucht.

Hab' ich was übersehen? Ich hab' nichts davon gelesen.

Upgrades verwenden weiterhin NTFS-3G, Neuinstallationen nicht.

Das betraf doch nur Upgrades von 22.04 ⇒ 22.04.1 etc., ja die wurden untersucht. Außerdem wurde nicht untersucht, ob sich das GUI-Mounten ohne zusätzliche udev-Regel aus 20.04 "vererbt".

Ich habe es nun mal selbst untersucht. Hier das Ergebnis.

Newubunti schrieb:

ÄNDERUNG START¶

[.....]

Temporäres Einbinden mittels grafischer Benutzeroberfläche¶

Gehören Benutzer der Systemgruppe sudo an, so können sie jede NTFS-Partition temporär^[1] einfach durch einen Klick

Ungültiges Makro

Dieses Makro ist nicht verfügbar

in z.B. den Porgrammen Nautilus oder Laufwerke einhängen

Hier sollte man noch ergänzen:

, sofern diese nicht zur Vorbereitung in /etc/fstab eingetragen ist

. Die betreffende Partition wird dabei standardmäßig wie üblich, in ein Verzeichnis unterhalb von /media/$USER privat - d.h. nur für den Benutzer der den Klick ausgeführt hat zugänglich - in den Dateibaum eingebunden.

[.....]

Statisches Einbinden¶

Soll die Partition statisch gemountet werden, lautet der entsprechende Eintrag in /etc/fstab ^[2]:

UUID=58CC69AFCC6987D8 /media/Bilder ntfs defaults 0 0

Hier würde ich einen extra Abschnitt ansetzen, denn das ist ja nun wirklich was anderes z.B:

Vorbereitetes Einbinden¶

Möchte man das Einbinden durch die Option noauto nur vorbereiten - um z.B. das Verzeichnis in das eingebunden werden soll, bestimmen zu können oder weitere Optionen vorzugeben, z.B. windows_names - so muss man beachten, dass das nachträgliche Einbinden in der grafischen Benutzeroberfläche für unprivilegierte Nutzer

"für unprivilegierte Nutzer" kann weg, denn bei vorhandenem fstab-Eintrag gilt das auch für Benutzer mit sudo-Recht.

nur unter den Voraussetzungen von #Temporäres-Einbinden-mittels-grafischer-Benutzeroberfläche

Meinst Du hier nicht eher: #Besonderheiten-bei-unprivilegierten-Nutzern ?

möglich ist und die betreffenden Nutzer bei Nutzung des Terminals udisksctl statt mount verwenden müssen!

da war ein Tippfehler

ÄNDERUNG ENDE¶

Kritik wie immer ausdrücklich willkommen!

Abseits meiner Änderungsvorschläge finde ich die Anleitung außerordentlich gut gelungen.

UlfZibis schrieb: Danke, für die Rückmeldung!

"für unprivilegierte Nutzer" kann weg, denn bei vorhandenem fstab-Eintrag gilt das auch für Benutzer mit sudo-Recht.

Richtig ist, dass sowohl Mitglieder der Gruppe sudo als auch unprivilegierte Nutzer zur Eingabe des Passwortes des Sysemverwalter-Kontos aufgefordert werden, sobald ein Eintrag in der /etc/fstab besteht. Nur ein unprivilegierter Nutzer hat ja das Passwort des Systemverwalter-Kontos in aller Regel nicht. Der unprivilegierte Nutzer kann damit gar nicht Einhängen, der Systemverwalter kann nach Eingabe seines Passwortes einhängen. Auch kann der Systemverwalter mit z.B. sudo mount /mnt/Bilder einhängen. Der unprivilegierte Nutzer kann das nicht.

Natürlich wäre es auch eine Möglichkeit einem unprivilegierten Nutzer über /etc/sudoers die Nutzung von mount /dev/disk/by-uuid/XXXXX... /mnt/Bilder ohne Passwort-Eingabe zu erlauben. In aller Regel will ja aber der unprivilegierte Nutzer lieber über GUI mounten.

Ansonsten kann man Deine Vorschläge so umsetzen.

LG, Newubunti

Newubunti schrieb:

Richtig ist, dass sowohl Mitglieder der Gruppe sudo als auch unprivilegierte Nutzer zur Eingabe des Passwortes des Sysemverwalter-Kontos aufgefordert werden,

Für gänzlich unprivilegierte Nutzer mag das so sein, Mitglieder der Gruppe sudo erhalten jedoch statt dessen die berühmte Fehlermeldung.

UlfZibis schrieb:

Newubunti schrieb:

Richtig ist, dass sowohl Mitglieder der Gruppe sudo als auch unprivilegierte Nutzer zur Eingabe des Passwortes des Sysemverwalter-Kontos aufgefordert werden,

Für gänzlich unprivilegierte Nutzer mag das so sein, Mitglieder der Gruppe sudo erhalten jedoch statt dessen die berühmte Fehlermeldung.

Das kann ich mit meinen Testsystemen (beruhend auf Neuinstallationen) so nicht nachvollziehen. Es verhält sich bei mir so, wie im Artikel beschrieben. Dein Problem hat IMO etwas damit zu tun, dass Du ein gewachsenes System hast. Bitte Verständnisfragen speziell zu Deinem System, weiterhin in Deinem Thread klären. Ich beantworte Dir Fragen dort weiterhin gerne - soweit möglich.

Hinweis: Ich gehe beim Schreiben von Wiki-Artikeln bzw. Teilen davon stets von der Situation auf Neuinstallationen aus. Alles andere ist schlichtweg nicht reproduzierbar.

Newubunti schrieb:

Das kann ich mit meinen Testsystemen (beruhend auf Neuinstallationen) so nicht nachvollziehen. Es verhält sich bei mir so, wie im Artikel beschrieben.

Du arbeitest auf einer VM. Kann das der Grund sein?

Dein Problem hat IMO etwas damit zu tun, dass Du ein gewachsenes System hast.

Nee, das 22.10 ist auch nur ein Test-System, war nach Neuinstallation schon so. Und vom Live-Medium aus verhält es sich auch so.

Wenn eine Passwort-Abfrage käme, wäre ich ja zufrieden (auch wenn das auf ⇐ 20.04 nicht nötig war) und hätte nie ein Problem gemeldet.

@UlfZibis:

Lass uns doch bitte - da Dein anderer Thread nun auch schon mal besteht - die Besonderheiten Deines Systems in Deinem Thread herausarbeiten. Dann kann man gegebenenfalls sehen, ob sich dort erlangte Kenntnisse verallgemeinern lassen, so dass sie dann hier einfließen können.

Jedenfalls ein Live-System ist zum Testen von Aktionen die gegebenenfalls Root-Rechte erfordern völlig ungeeignet.

LG, Newubunti

Ich befürchte, wir geraten schon wieder in Details, die nicht nötig und vor allem auch nicht NTFS-3 spezifisch sind.

Das Problem der "Fehlermeldung von UlfZibis sollten wir besser erst ’mal außen vor lassen, da es nicht reproduziert werden kann. Irgend etwas muss da besonders sein, woran man auf den ersten Blick nicht denkt. Kann es an den FUSE-Einstellungen liegen? Oder daran, dass der Mount-Prozess und der Mountpunkt nicht den gleichen Besitzer haben? Also lassen wir es im Wiki-Artikel ganz weg, solange wir nichts darüber wissen. Mit der VM hat das IMO ganz sicher nichts zu tun, mit dem Life-System vielleicht schon eher.

Einhängen über die GUI: Hier wird der Befehl gio mount -d /dev/… ausgeführt. Welche Berechtigungen dafür nötig sind, steht im Artikel gio mount (bzw. sollte dort stehen). Speziell mit NTFS-3G hat das AFAIK nichts zu tun. Vieles könnte hier mit einem Link erledigt werden, was den Artikel NTFS-3G wohltuend entlasten würde.

Nebenbei (und nicht ganz off topic): Der Artikel gio mount ist wichtig und gehört jetzt unbedingt für Ubuntu 22.04 getestet! Ich sehe im Moment nichts, was an ihm nicht mehr stimmt, aber vermutlich sind Ergänzungen angebracht wegen udev-Regeln (?).

Ich würde dann, da auch im Wiki als solches dokumentiert, das GIO nennen (bei allen GTK-Oberflächen) und lieber nicht nur von GUI und dem einen Dateimanager sprechen. Auch hier bin ich für Vielfalt: Gnome, XFce, … und entsprechend Nautilus, Thunar, … Und Gigolo gehört beim GVfs ja auch dazu. Nur KDE ist ein bisschen anders.

Und die Unterschiede zwischen privilegierten und nicht privilegierten ("unterprivilegierten? 🙄 ) Nutzern kann ich nicht erkennen. Sicher, "privilegierte" können sich mittels sudo Root-Rechte verschaffen, andere nicht. Aber solange sie das nicht tun, sind doch alle gleich. Ein Unterschied ist wohl, ob der Prozess (das Mounten) und der Mountpunkt den gleichen Besitzer haben, und bei FUSE ist das noch ein bisschen komplizieter wegen allow_other (und bei uns im Wiki dürftig dokumentiert).

Sind Besonderheiten von Hint Systemen hier wirklich wichtig?? Und haben die wirklich etwas mit sudo-Berechtigung zu tun? Ist es nicht einfach so, dass nur Root und der Besitzer des Systems mounten dürfen? Doch ich kenne mich da nicht aus.

Mit udiskctl kenne ich mich leider gar nicht aus. Ab er ganz sicher handelt es sich nicht um etwas Spezifisches von NTFS-3G. Der Hinweis darauf gehört deshalb wohl in die Artikel mount und gio mount – bzw. eigener Artikel mit Link, sozusagen die dritte mount-Alternative.

Also mein Wunsch wäre: Alles in andere Artikel überführen, was nicht NTFS-3G spezifisch ist.

P.S. Bei NTFS muss man bei "unerklärlichen" Fehlern auch an das "dirty-Flag" denken. NTFS-3G und NTFS3 gehen damit unterschiedlich um.

Max-Ulrich_Farber schrieb:

Einhängen über die GUI: Hier wird der Befehl gio mount -d /dev/… ausgeführt.

Das verstehe ich nicht. Denn wenn GUI-Mount dasselbe tut, müsste beides doch gleichermaßen funktionieren, unter derselben udev-Regel. Bei mir ging dann nur udisksctl mount, gio mount aber nicht.

gio mount aber nicht.

Geht nur mit der Option -d bzw. --device (siehe man gio)

Max-Ulrich_Farber schrieb:

Geht nur mit der Option -d bzw. --device (siehe man gio)

Oh ja, tatsächlich. Die Fehlermeldung gab das leider nicht her, warum ich dann aufgegeben hatte. Also mal wieder ein Fall von RTFM.

Artikel ist nun in der Baustelle.

Artikel ist nun in der Baustelle.

Danke kB!

@Newubunti: es wäre schön, wenn du jetzt deine Änderungen und Ergänzungen dort einarbeiten könntest. Dabei möchte ich aber meinen Wunsch wiederholen:

• eine Überarbeitung der Artikel mount und gio mount ist überfällig! Dort sollte alles eingebracht werden, was allgemein udev-Regeln sowie (derzeit) udisks2 und auch udisksctl betrifft. Das wäre u.a. auch der Abschnitt "Besonderheit bei unprivilegierten Nutzern" und der Hinweis auf Hint-Systeme.

• Einen eigenen Artikel für udisks und udisksctl würde ich auch angebracht finden, da offenbar udisksctl schon per Default verwendet wird. Wenn dieser Artikel gut mit mount und gio mount verlinkt wird, ist ein Übersichtsartikel zum Einbinden von (beliebigen) Dateisystemen wohl nicht nötig. Den Artikel möchte und kann ich aber nicht verfassen.

• Die Gliederung nach "GIO mit Nautilus und Mausklick" einerseits und "Terminal bzw Kommandozeile andererseits" finde ich nicht glücklich. Besser fände ich eine Gliederung nach dem jeweils verwendeten mount-Programm: mount, gio mount und udisksctl. Alle können per Kommandozeile oder von irgendeinem Programm aus aufgerufen werden, und die graphischen Werkzeuge verwenden in GTK-Flavours eben das GVfs mit gio mount.

• Anstoß für diese neuerliche Überarbeitung war meine Absicht, den Artikel schlanker und damit besser lesbar zu machen, indem daraus alles entfernt bzw. ausgelagert wird, was sich nicht spezifisch auf den Treiber NTFS-3G bezieht. Diese Absicht möchte ich unbedingt beibehalten.

Ich verfasse jetzt ’mal eine neue Einleitung und bitte dann darum, diese (wohlwollend 😉 ) zu kritisieren.