staging.inyokaproject.org

@kaputtnik:

Du musst genau unterscheiden, welche Rechte Du (bzw. Root) brauchst, um mounten zu können, und welche Rechte Du dann brauchst, um auf dem gemounteten Gerät arbeiten zu können. Das ist zweierlei! Es kann ja auch sein, dass jemand ganz anderes das Gerät mountet als derjenige, der nachher darauf arbeitet.

Um ein Gerät einzubinden, muss man zunächst Schreibzugriff auf den Einhängepunkt haben.

Das bezieht sich auf das Mounten selbst. Ohne Schreibrechte auf dem Mountpunkt kann man nicht mounten. Das hat gar nichts damit zu tun, ob man nachher auf das gemountete Gerät schreiben darf/kann, oder nicht.

Aber wenn die Rechte des eingehängten Dateisystems die Rechte des Einhängepunktes "überdecken" (ich würde verstehen "überschreiben" was sicherlich nicht ganz korrekt ist), dann sind die Rechte des Einhängepunktes doch eigentlich egal?

"Überschreiben" würde ich nicht sagen, denn sie sind ja nicht definitiv weg; nach dem Unmounten sind sie wieder da! "Überdecken" finde ich da schon richtig. Egal sind die Rechte des Einhängepunktes erst nach dem Mounten. Sie sind aber vorher entscheidend dafür, ob man überhaupt mounten kann.

Ich muss einmal den Artikel in Ruhe durchsehen, ob und wie man durch Änderungen in der Ausdrucksweise diesen Unterschied klarer hervorheben kann.

Noch ein Stück weiter zurück im Thread:

Aber der Benutzer heißt jetzt anders! Und woher soll das Rechtesystem wissen, das User "kaputtnik" = "franky" ist? Ich habs ihm nicht gesagt 😉 Wenn ich jetzt eine Festplatte von einem anderen User bekomme, dann kann ich genauso darauf herumschreiben...

Was im Dateisystem - bzw. genauer in der Verzeichnisstruktur - gespeichert ist, sind nur UID und GID, nicht die Namen. Wenn beim Anlegen der Datei "Kaputtnik" die UID 1000 hatte, und jetzt hat "Frankie" die UID 1000, dann gilt Frankie als derselbe Benutzer und hat die Rechte so wie vorher Kaputtnik. Wenn Kaputtnik selbst jetzt die UID 1001 hat, vorher aber 1000 hatte, ist er nicht mehr der gleiche, und hat seine Rechte verloren. Nur UID und GID sind entscheidend!

Gruß - Max-Ulrich

Max-Ulrich Farber schrieb:

Um ein Gerät einzubinden, muss man zunächst Schreibzugriff auf den Einhängepunkt haben.

Das bezieht sich auf das Mounten selbst. Ohne Schreibrechte auf dem Mountpunkt kann man nicht mounten.

Da musst ich nochmal was einwerfen: Um eine Partition zu mounten benötigt man keine Schreib- oder Leserechte für den Einhängepunkt-Ordner.

Um eine Partition zu mounten benötigt man keine Schreib- oder Leserechte für den Einhängepunkt-Ordner.

Wenn man das Gerät mit Root-Rechten (mittels sudo) mountet, was ja der übliche Weg ist, dann muss halt "Root" Schreibrechte haben. Ich habe es noch nie probiert, aber es wäre mir völlig neu, wenn man in einen Ordner mit mode 0555 mounten könnte. Ich will's gleich probieren!

Einige von mount verwendete Hilfsprogramme wie mount.cifs oder mount.sshfs sind sogar noch strenger: Sie fordern, dass der Mountpunkt Besitz desjenigen ist, der mountet.

Gruß - Max-Ulrich

EDIT:

Jetzt habe ich wieder etwas gelernt (danke, primus pilus)! 😳 Ja, man kann mounten, ohne Schreibrechte auf dem Mountpunkt zu haben - zumindest solange keine Zusatz-Routinen wie mount.cifs verwendet werden. Wie es da ist, muss ich noch eigens erkunden - aber das mit dem Eigentum habe ich zumindest bereits überprüft.

Das ist sogar ganz praktisch: Man kann z.B. in einem Netzwerk oder bei externen Datenträgern den Mountpunkt read only machen, dann kann es nicht passieren, dass man versehentlich auf diesen schreibt, wenn der Datenträger oder die Freigabe nicht gemountet ist. Vorausgesetzt, es geht mit den Netzwerk-Dateisystemen genau so.

@kaputtnik: Somit hast Du Recht: Die Rechte des Mountpunktes sind fürs "normale" Mounten offenbar wirklich egal!

nochmal EDIT:

Aber irgendwie fies ist das doch! Wenn jeder überallhin mounten darf, auch ohne Schreibrechte zu haben, dann kann mir jeder meine Ordner "verschließen" oder scheinbar verschwinden lassen, indem er z.B. mit mount --bind irgendwas drüberlegt, auf das ich keinen Zugriff habe. Wenn ich nicht zu den sudoers gehöre, kann ich gar nichts dagegen machen - sofern ich überhaupt realisiere, was da passiert ist. - Nun ja, mounten können ja nur sudoers, die tun so etwas nicht...

Vielleicht ist das der Grund, warum z.B. bei mount.cifs, für das standardmäßig das SUID-Bit gesetzt ist, verlangt wird, dass der Mountpunkt demjenigen gehört, der mountet.

Ich muss mal sehen, ob wenigstens die Rechte des übergeordneten Verzeichnisses das Mounten einschränken können.

kaputtnik schrieb:

zod schrieb:

kaputtnik schrieb:

Welche Bedeutung hat der Satz: "Ich habe ein gutes Dateisystem!" ❓

Das "gut" bezieht sich ja auf ganz bestimmte Eigenschaften des Dateisystems. Das DS könnte z.B. so organisiert sein, dass es nicht zur Fragmentierung neigt oder dass es Zugriffsrechte der Dateien speichern kann.

Und was ist, wenn eine "gute Verzeichnistruktur" gemeint war?

Wenn du jemanden mitteilen möchtest, dass dein Auto gute Reifen hat, sagst du dann auch: "Ich hab ein gutes Auto" ? Macht doch irgendwie keinen Sinn, oder? Ich versteh auch ehrlichgesagt nicht so ganz was diese Frage soll..

Eine "Entität" ist genau dann Teil von etwas (Festplatte/Partition/Dateisystem) wenn es sich in dessen Zuständigkeitsbereich befindet. Diese Zuständigkeitsbereiche können z.B. in der Partitionstabelle und im Verwaltungsblock eines Dateisystems festgelegt werden.

Hört sich das vernünftig an?

Ehrlich gesagt: Ich weiß nicht was Du damit jetzt sagen willst. Ich weiß auch auch nicht, welchen Bezug das zum Artikel mount hat, über den es hier ja eigentlich geht.

Du hast behauptet, dass die Rechte in der VS gespeichert werden (im mount-Artikel steht im DS) und dass das VS und DS zwei völlig verschiedene Dinge sind. Damit wollte ich nur das Prinzip erklären, nachdem etwas als Teil eines z.B. Dateisystems bezeichnet werden kann.

Vllt sollten wir diese Diskussion lieber per PN oder Jabber führen...

Ich weiß nicht ob das einen großen Vorteil hat. Hier können sich wenigstens noch andere beteiligen. Außerdem ist jetzt das meiste wahrscheinlich sowies schon gesagt..

zwitschernder Zwerg schrieb:

2) enthält alle irgendwie möglichen/denkbaren hardwarenahen Einhängepunkte, (nicht bloss die "vorhandenen")

Nee, die Annahme ist ziemlich falsch. unter /dev liegt - etwas vereinfacht gesagt - so gut wie alle, was auf Hardware zugreift. Also auch USB, Firewire usw.

Weiterhin war das früher so, dass /dev mit jede Menge Unterverzeichnisse angelegt wurden. Zur "Abhilfe" wurde dann udev eingeführt, welche Verzeichnisse unter /dev dynamisch anlegen kann.

3) an welche die tatsächlich gefundenen Geräte zunächst mal tatsächlich angehängt werden (die genaue Belegung bekommt man aber NICHT mit "mount" ohne Parameter raus)

Stimmt, mount hat damit nichts_ zu tun, s.o.

5) die man benutzen sollte um sie mit mount tatsächlich an irgendeine Stelle im Verzeichnisbaum einzuhängen, wo man mit ihnen sinnvoll arbeiten möchte

Na ja, das ist einfach: alles einhängen, worauf du zugreiffen willst. Das ist für gängigen Speichermedien i.d.R. /dev/sdX

tatsächlich würde es mich interessieren, ob es eine "Datei" (oder einen Befehl) gibt, in welcher aufgelistet ist, welche hardware an welchen Punkt in /dev/ wirklich angehängt wurde (lshw tut das ja leider nicht...) - damit man ein mount sinnvoll durchführen kann...

mount 

☺

Wenn ich das verstanden hab' ändere ich den Artikel gerne, ansonsten kann auch gern jemand den Artikel ändern und ich schau mal ob ich's verstanden hab 😉

Deine Fragen haben zu 90% nicht wirklich was mit mount zu zun, sondern mit dem Verständis von Device-Dateien unter Linux.

Gruß, noisefloor

Ganz kurz:

Es gibt den Artikel Dateisystem. Darin wird meines Erachtens das Dateisystem als ein auf dem Rechner konkret vorhandenes Dateisystem und nicht als eine abstrakte Dateisystem-Struktur verstanden. Ich habe also ein anderes Dateisystem als - sagen wir Kaputtnik, obwohl beide von der Art ext3 sind. Wenn mein Dateisystem beschädigt ist, kann das von Kaputtnik noch intakt sein. Die "Dateistruktur von Linux", die der Artikel ausdrücklich nicht behandeln will, ist hingegen ein abstraktes Ordnungsprinzip, also für Kaputtnik und für mich gleich.

Dieser Wortgebrauch ist gerade umgekehrt wie der, den Kaputtnik vorschlägt. Er ist in sich aber auch nicht konsequent, denn so gesehen ist ext3 kein Dateisystem, sondern eine Dateisystem-Art.

Ich sehe im Moment keinen Ausweg aus dem begrifflichen Dilemma, das kaputtnik - meines Erachtens zu Recht - stört. Nicht sehr trostreich: Es gibt noch einige andere Beispiele, wo gleiche Begriffe für einzelne Repräsentanten und für ganze Klassen verwendet werden. Wie ist es z.B. bei "Betriebssystem"? Ist Linux (oder Ubuntu) ein Betriebssystem? Ich kann mein Betriebssystem zerschießen. Kann ich deshalb Linux zerschießen??

Was tun, ohne dass man alles noch komplizierter macht?

Gruß - Max-Ulrich

Max-Ulrich Farber schrieb:

nochmal EDIT:

Aber irgendwie fies ist das doch! Wenn jeder überallhin mounten darf, auch ohne Schreibrechte zu haben, dann kann mir jeder meine Ordner "verschließen" oder scheinbar verschwinden lassen, indem er z.B. mit mount --bind irgendwas drüberlegt, auf das ich keinen Zugriff habe. Wenn ich nicht zu den sudoers gehöre, kann ich gar nichts dagegen machen - sofern ich überhaupt realisiere, was da passiert ist. - Nun ja, mounten können ja nur sudoers, die tun so etwas nicht...

Naja, du benötigst ja Rootrechte um die fstab zu ändern. Daher kann dieses „wilde mounten“ (hihi) ja nur von einem Nutzer mit Rootrechten ausgehen. Und wenn jemand Rootrechte hat kann ihn so wie so nichts aufhalten.

Das stimmt natürlich auch wieder. Und bei den "gefährlichen" Routinen wie mount.cifs, mit denen jeder auch ohne fstab-Eintrag mounten kann, ist es ja zum Glück nicht so.

Nebenbei spielen auch die Rechte des übergeordneten Verzeichnisses bei mount offenbar keine Rolle (wie das z.B. bei mkdir, rmdir oder bei einer Namensänderung der Fall wäre).

Ich mache den Satz mit den Schreibrechten jetzt raus.

Gruß und Danke für die Aufklärung!

Max-Ulrich

@Max-Ulrich Faber und @noisefloor stimmt, ich hatte das /dev - Verzeichnis nicht ganz verstanden. Herzlichen Dank für die Tips - ich habe jetzt mit den Artikeln zu udev und Datenverwaltung (ojemineh, wer hat sich DEN Titel ausgedacht, ich hatte darunter einen Einführungsartikel in unterschiedliche Datenbanken erwartet...) einiges mehr verstanden. Außerdem fand ich zum Verständnis der in /dev aufgeführten Einträge ebenfalls hilfreich, die flags eines mit ls -al gelisteten Eintrags verstehen zu können (also den ERSTEN Buchstaben eines ls -al Eintrags)
"d" = directory
"l" = link
"-" = file
"p" = pipe
"b" = block special device
"c" = character special device
"b" und "c" sind also Indikatoren für "Geräte"-Einträge (weil sie Blockweise, bzw. Zeichenweise gelesen werden)

Frage: Auch wenn udev und Datenverwaltung "nur Grundlagen" sind, gehören solche Kenntnisse nicht als Voraussetzung auch in den Abschnitt: "Diese Anleitung setzt die Kenntnis folgender Seiten voraus:" ?

Tja und dann noch die Frage die wahrscheinlich nicht ganz hierher gehört: Meine neue Festplatte (jungfräulich auf ext3 formatiert) produziert ZWEI Einträge in /dev: /dev/sdb UND /dev/sdb1 - woher weiss ich, dass ich /dev/sdb1 mounten muss und NICHT /dev/sdb ? oder ist es doch egal?

(und, ganz OT: warum gibt es in meinem /dev genau 325 Einträge ttyXY???)

zZ

zwitschernder Zwerg schrieb:

Tja und dann noch die Frage die wahrscheinlich nicht ganz hierher gehört: Meine neue Festplatte (jungfräulich auf ext3 formatiert) produziert ZWEI Einträge in /dev: /dev/sdb UND /dev/sdb1 - woher weiss ich, dass ich /dev/sdb1 mounten muss und NICHT /dev/sdb ? oder ist es doch egal?

/dev/sdb ist die Festplatte, /dev/sdb1 ist die erste Partition auf sdb, sdb2 die 2. P. usw. du kannst nur Partitionen einhängen.

und, ganz OT:

Genau, bitte eröffne dazu ein Thema in einem Support Forum. Das passt nun wirklich nicht in die Diskussion zu dem Artikel.

kaputtnik schrieb:

zod schrieb:

Der Begriff Dateisystem ist ein Synonym für eigentlich zwei ganz unterschiedliche Dinge.

Das seh ich etwas anders. Denn wenn mans ganz genau nimmt ist eine Verzeichnisstruktur eine Teilmenge eines Dateisystems.

Nö, ein Dateisystem stellt erst die Möglichkeit zur Verfügung, eine Verzeichnisstruktur (mit Rechtevergabe) anzulegen.

Sorry, wenn ich jetzt hier so reinplatze, aber zod hat Recht. (Ich gebe zu, nur Seite 1 dieses Threads glesen zu haben.) Ein Dateisystem kann eine Verzeichnisstruktur beherbergen, muß aber nicht. Das ist regelmäßig direkt nach dem Formatieren der Fall.

Ein Dateisystem wird durch das Formatieren erzeugt. Bsp. ext: Es werden z.B. Metadaten in sog. Inodes gespeichert wie

• Zugriffszeiten;

• Dateirechte;

• aber auch Verweise wo sich der Inhalt einer Datei physisch auf dem Datenträger befindet;

• etc.

Da die Anzahl der Inodes begrenzt ist, kann es deshalb mitunter zu folgender, Situation kommen: Eine Parition sei 5 GB groß. In dieser Partition werden extrem viele sehr kleine Dateien gespeichert; meinetwegen mit einer Gesamtgröße von nur 2 GB. Jede Datei benötigt jedoch eine Inode. Sobald keine Inode mehr frei ist kann keine einzige Datei mehr in der Partition gespeichert werden, obwohl ja noch 3 GB "frei" sind. Das Dateisystem ist dann voll. Das ist für User ohne das entsprechende Hintergrundwissen schlicht unverständlich.

Ich hoffe ich konnte Dir die Bedeutung von "Dateisystem" im Gegensatz zu "Verzeichnisstuktur" etwas näher bringen.

Moin,

nochmal zur Diskussion "Verzeichnisstruktur" vs. "Dateisystem":
Ich glaube wir haben einfach eine andere Sichtweise auf die Dinge. Ihr seht es technisch/abstrakt, ich sehe es praktisch/konkret. Natürlich habt Ihr Recht, wenn Ihr sagt "Eine Verzeichnisstruktur ist Teil eines Dateisystems". Ohne Dateisystem wäre das Anlegen einer Verzeichnisstruktur ja auch nicht so einfach möglich (genaugenommen wäre es zwar möglich, aber dann müsste ich mich selber um die Implementierung und Steuerung kümmern, dann müsste ich selber dafür sorgen zB Inodes anzulegen). Diese Arbeit erledigt aber das Dateisystem für mich. Es "läuft" unsichtbar im Hintergrund. Ich bekomme davon nichts mit. Im Gegensatz dazu kann ich eine Verzeichnisstruktur "fühlen", ich kann sie sehen und mit wenigen Ausnahmen sogar selber anlegen/verändern. Ich habe direkten Einfluss darauf. Es ist etwas konkretes, nichts abstraktes. Letztendlich kann mir das Dateisystem(ext3/NTFS) fast schnurz sein, Hauptsache ich kann damit meine Verzeichnisse so Anlegen, wie ich das für richtig halte...

Versteht Ihr jetzt, warum ich sage: Es sind zwei unterschiedlich Dinge? Vllt wäre es besser von unterschiedlichen "Ebenen" zu sprechen, einer unsichtbaren "Verwaltungsebene" und einer sichtbaren "Benutzerebene".

primus pilus schrieb:

/dev/sdb ist die Festplatte, /dev/sdb1 ist die erste Partition auf sdb, sdb2 die 2. P. usw. du kannst nur Partitionen einhängen.

So kann mans auch sagen 😉

Ich versuche mal, den Abschnitt etwas verständlicher zu machen:

Rechte

Um ein Gerät eine Partition (genauer: Ein Dateisystem) einzubinden, spielen die Rechte des Einhängepunktes in der Regel keine Rolle (Ausnahmen gelten bei Netzwerk-Dateisystemen). Nach dem Einbinden überdecken die Rechte des eingehängten Dateisystems die des Einhängepunktes. Hier gibt Es gibt jedoch prinzipielle Unterschiede, je nachdem, ob das eingehängte Dateisystem die Unix-Rechteverwaltung unterstützt (z.B. ext2, ext3, ReiserFS) oder nicht (z.B. FAT, NTFS).

Dateisysteme mit UNIX-Rechteverwaltung: Das Dateisystem nimmt die Rechte von vorhandenen Dateien und Verzeichnissen beim Einbinden an einen beliebigen Ort quasi "mit". Denn die Rechte sind im jeweiligen eingehängten Dateisystem gespeichert und nicht etwa "im" oder "am" Einhängepunkt. Daher sind die Rechte des Einhängepunkt-Verzeichnisses auch nicht weiter relevant für das Einbinden - entscheidend sind die Rechte im eingehängten Dateisystem. Beim Einhängen können diese jedoch grundsätzliche Rechte über die Einhänge-Optionen bzw. die Einträge in der fstab nur noch weiter eingeschränkt vergeben werden (z.B.: "Nur lesbar"). Diese zusätzlichen Einschränkungen gelten dann nur für diesen Einhängepunkt Einhängevorgang und werden nicht im eingehängten Dateisystem eingetragen.

Nach dem Einhängen können die Rechte der Verzeichnisse und Dateien in einem solchen Dateisystem mit den Befehlen chown und chmod verändert werden; die Einhänge-Optionen legen dabei nur den Rahmen fest, innerhalb dessen dies gestattet ist die Rechte nachträglich geändert werden können.

Was haltet ihr davon?

Desweiteren würde ich gerne mein Eingangsproblem als Beispiel am Ende eintragen:

7. Eine neu formatierte Partition einhängen Ein neu erstelltes Dateisystem auf einer Partition scheint leer, enthält aber bereits das sogenannte Wurzelverzeichnis. Da man nur als root eine Partition Formatieren kann, ist auch der Besitzer des Wurzelverzeichnisses immer root. Will man eine solche Partition mit Lese- und Schreibrechten versehen, so müssen die Rechte des Wurzelverzeichnisses geändert werden.

sudo mount /dev/sdb1 /media/neuepartition
sudo chown :plugdev /media/neuepartition 

Sollte die Gruppe 'plugdev' keine Schreibrechte besitzen, so muss man diese zusätzlich einrichten:

sudo chmod g+w /media/neuepartition 

Grüße
kaputtnik

Hallo kaputtnik,

den meisten Formulierungs-Verbesserungen, die Du vorschlägst, kann ich ohne Weiteres zustimmen. Du hast Dir da gründlich Gedanken gemacht. Ein paar Stellen sehe ich aber doch anders:

Beim Einhängen wurde bewusst von "Geräten" und nicht nur von "Partitionen" gesprochen, denn Du kannst auch ein Floppy-Laufwerk oder ein CD-ROM oder DVD-RW oder einen USB-Stick einhängen, und alle diese Geräte kennen keine Partitionen (der USB-Stick im Prinzip zwar schon, aber es ist nicht üblich). Du kannst eben alles einhängen, wovon Du Daten lesen oder worauf Du Daten schreiben kannst. Bei /dev spricht man ja auch von "Gerätedateien", obwohl darin einzelne Partitionen aufgeführt sind.

Ich würde deshalb bei "Gerät" bleiben, aber oben eine Erklärung einfügen, dass partitionierte Festplatten logisch als mehrere einzelne Geräte anzusehen sind.

Dir ist sicher bewusst, dass auch Deine sehr überlegten Formulierungen die letzte Schärfe nicht haben bzw. nicht haben können. Man bindet eigentlich keine Geräte und keine Partitionen ein, sondern eben nur deren Dateisysteme. Das hast Du ja in Klammern angedeutet. Das Wort "Verzeichnisstruktur" würde ich nach all den Überlegungen lieber außen vor lassen. - Ich meine aber, wir sollten auch nicht zu spitzfindig sein.

Zum von Dir anfügten Punkt 7: Das alles stimmt so für Festplatten-Partitionen mit einem Linux-Dateisystem, aber eben nur da. Weil, wie ich gesehen habe, gerade in Ubuntu als typischem Umsteiger-System unwahrscheinlich viel auch mit Windows-Partitionen oder mit USB-Sticks usw. gearbeitet wird, die schon mit VFAT vorformatiert sind, sollte man hier genau differenzieren!

Noch ein Punkt führt immer wieder zu Missverständnissen: Auch bei Windows-Dateisystemen können in dem durch die (dort viel differenzierteren) Mount-Optionen vorgegebenen Rahmen Rechte nachträglich verändert werden. Aber diese Veränderungen sind eben nicht nachhaltig, denn sie werden hier nicht auf der gemounteten Partition, sondern nur auf dem Client (am Mountpunkt, wenn man das so sagen darf) registriert ("simuliert") und sind nach dem Unmounten deshalb wieder weg. Sie kleben aber - soweit ich sehe - auch nicht dauerhaft am Mountpunkt, sondern verschwinden beim Unmounten im Nirwana. Auch hierauf wird in dem Artikel nicht genügend klar eingegangen.

Wenn ich das alles so sehe, frage ich mich, ob man nicht am besten den Artikel für ca. 14 Tage wieder in eine Baustelle verschieben sollte, dann kann man ruhiger gemeinsam daran arbeiten. Was meinst Du? Und was meint noisefloor?

Gruß - Max-Ulrich

kaputtnik schrieb:

Ich versuche mal, den Abschnitt etwas verständlicher zu machen:

Rechte ... Dateisysteme mit UNIX-Rechteverwaltung: Das Dateisystem nimmt die Rechte von vorhandenen Dateien und Verzeichnissen beim Einbinden an einen beliebigen Ort quasi "mit". Denn die Rechte sind im jeweiligen eingehängten Dateisystem gespeichert und nicht etwa "im" oder "am" Einhängepunkt. Daher sind die Rechte des Einhängepunkt-Verzeichnisses auch nicht weiter relevant für das Einbinden - entscheidend sind die Rechte im eingehängten Dateisystem. Beim Einhängen können diese jedoch grundsätzliche Rechte über die Einhänge-Optionen bzw. die Einträge in der fstab nur noch weiter eingeschränkt vergeben werden (z.B.: "Nur lesbar"). Diese zusätzlichen Einschränkungen gelten dann nur für diesen Einhängepunkt Einhängevorgang und werden nicht im eingehängten Dateisystem eingetragen.

Servus. Jetzt dürfen wir aber nicht anfangen Mountoptionen und Dateirechte durcheinander zu werfen! Die Mountoptionen sind Anweisungen an das OS (also den Kernel) wie mit dem Dateisystem umgegangen werden soll. Mit den Dateirechten hat das nichts zu tun.

Schau mal:

daniel@Octopus:/mnt$ ls -l
insgesamt 4
drwxr-xr-x 2 root root 4096 2010-01-12 12:08 Daten
daniel@Octopus:/mnt$ sudo mount -t ntfs -o defaults,ro /dev/sda2 /mnt/Daten/               # eine ntfs-Partition Read-only mounten
daniel@Octopus:/mnt$ ls -l
insgesamt 4
drwxrwxrwx 1 root root 4096 2010-01-06 23:38 Daten                      # Hier steht was von (Datei-)Schreiberechten. (Liegt an ntfs.)

daniel@Octopus:/mnt$ cp /home/daniel/testfile /mnt/Daten/                 # Versuche eine Datei auf das ro-Filesystem zu kopieren.
cp: reguläre Datei „/mnt/Daten/testfile“ kann nicht angelegt werden: Read-only file system

daniel@Octopus:/mnt$ sudo umount /mnt/Daten/
daniel@Octopus:/mnt$ sudo mount -t ntfs -o defaults /dev/sda2 /mnt/Daten/             # neu mounten, diesmal rw
daniel@Octopus:/mnt$ ls -l
insgesamt 4
drwxrwxrwx 1 root root 4096 2010-01-06 23:38 Daten

daniel@Octopus:/mnt$ cp /home/daniel/testfile /mnt/Daten/                  # Dieses Mal klappt das kopieren.
daniel@Octopus:/mnt$ ls -l /mnt/Daten/testfile 
-rwxrwxrwx 1 root root 38 2010-01-12 12:12 /mnt/Daten/testfile  # Die Dateirechte/Besitzer/primäre Gruppe hat ntfs zerrissen, weil es das nicht unterstützt. Siehe:

daniel@Octopus:/mnt$ ls -l /home/daniel/testfile 
-rw-r--r-- 1 daniel daniel 38 2010-01-12 11:51 /home/daniel/testfile         

Die Befehle chown und chmod habe ich nicht verwendet.

Nach dem Einhängen können die Rechte der Verzeichnisse und Dateien in einem solchen Dateisystem mit den Befehlen chown und chmod verändert werden; die Einhänge-Optionen legen dabei nur den Rahmen fest, innerhalb dessen dies gestattet ist die Rechte nachträglich geändert werden können.

Das setzt ein rw-gemountetes Dateisystem mit UNIX-Dateirechten voraus.

Hallo,

ob man nicht am besten den Artikel für ca. 14 Tage wieder in eine Baustelle verschieben sollte, dann kann man ruhiger gemeinsam daran arbeiten

Meinetwegen bzw. gute Idee.

EDIT:

Jetzt dürfen wir aber nicht anfangen Mountoptionen und Dateirechte durcheinander zu werfen! Die Mountoptionen sind Anweisungen an das OS (also den Kernel) wie mit dem Dateisystem umgegangen werden soll. Mit den Dateirechten hat das nichts zu tun.

So isses. Mit den Optionen -o ro bzw. -o rw wird festgelegt, ob man (=JEDER Benutzer inkl. Root) überhaupt auf das System schreiben darf.

Gruß, noisefloor