Eigentumsrechte bei vfat mounten
Hallo, Wieso geht das nicht: maik@syl:~ $ chmod 777 /sicher maik@syl:~ $ ls -ld /sicher drwxr-xr-x 12 maik users 16384 Mai 4 02:10 /sicher maik@syl:~ $ grep vfat /etc/fstab /dev/hda12 /sicher vfat user,uid=500,gid=100,auto 0 0 ,----[ man fstab ] | uid=value and gid=value | Set the owner and group of all files. (Default: the | uid and gid of the current process.) `---- Wenn ich doch Eigentümer bin sollte ich doch wohl auch die Rechte ändern können wie ich will, oder? -- :wq-y Maik
Hallo, On Sat, 04 May 2002, Maik Holtkamp wrote:
Wieso geht das nicht: maik@syl:~ $ chmod 777 /sicher maik@syl:~ $ ls -ld /sicher drwxr-xr-x 12 maik users 16384 Mai 4 02:10 /sicher maik@syl:~ $ grep vfat /etc/fstab /dev/hda12 /sicher vfat user,uid=500,gid=100,auto 0 0
,----[ man fstab ] | uid=value and gid=value | Set the owner and group of all files. (Default: the | uid and gid of the current process.) `----
Wenn ich doch Eigentümer bin sollte ich doch wohl auch die Rechte ändern können wie ich will, oder?
AFAIK spielt da auch noch die umask ne Rolle (die man auch mit mount aendern kann), aber mit der steh ich auch auf Kriegsfuss... Ich bekomm's auch nicht so hin, wie ich will... Wenn ich mounte, hat bei mir z.Z. alles das x-bit, chmod a-x auf Dateien geht aber... ~ $ mount | grep /winc /dev/hda1 on /winc type vfat (rw,noexec,nosuid,nodev,umask=007,uid=500,gid=100,user=dh) ~ $ cd /winc/temp ~ $ touch foo /winc/temp $ l foo -rwxrwx--- 1 dh users 0 May 4 04:39 foo* /winc/temp $ chmod 607 foo /winc/temp $ l foo -rw-rw---- 1 dh users 0 May 4 04:39 foo /winc/temp $ rm foo Offenbar gilt auch beim chmod (irgendwie) die umask des mountens... Wieso hier g=rw noch gilt??? IMO muesste da man wohl mal in die Untiefen des (v)fat-Treiberes absteigen... :((( Naja... Es "nervt a bisserl", weil ne umask=117 auch den dirs das x-bit entzieht... Aber ich brauch das zum Glueck eh nur noch sehr selten ;) -dnh -- "Phnglui mgwlnafth Cthulhu rlyey wghnagl fthagn." "In his flat in Bromley, drunk Cthulhu waits knitting? I think a few subtle typos may have crept into that one." "That explains why this shoggoth I summoned is only 3mm tall." - Peter da Silva and Peter Gutmann in the scary.devil.monastery
Hy, Am 02/05/04@04:46 schrieb David Haller:
Hallo,
On Sat, 04 May 2002, Maik Holtkamp wrote:
Wieso geht das nicht: maik@syl:~ $ chmod 777 /sicher maik@syl:~ $ ls -ld /sicher drwxr-xr-x 12 maik users 16384 Mai 4 02:10 /sicher maik@syl:~ $ grep vfat /etc/fstab /dev/hda12 /sicher vfat user,uid=500,gid=100,auto 0 0
,----[ man fstab ] | uid=value and gid=value | Set the owner and group of all files. (Default: the | uid and gid of the current process.) `----
Wenn ich doch Eigentümer bin sollte ich doch wohl auch die Rechte ändern können wie ich will, oder?
AFAIK spielt da auch noch die umask ne Rolle (die man auch mit mount aendern kann), aber mit der steh ich auch auf Kriegsfuss... Ich bekomm's auch nicht so hin, wie ich will... Wenn ich mounte, hat bei mir z.Z. alles das x-bit, chmod a-x auf Dateien geht aber... [...] Offenbar gilt auch beim chmod (irgendwie) die umask des mountens... Wieso hier g=rw noch gilt??? IMO muesste da man wohl mal in die Untiefen des (v)fat-Treiberes absteigen... :(((
Der vfat Treiber muss noch irgendwelchen anderen Probleme haben. Drauf gestoßen war ich eigenlich als ich gestern mit dem letzten transcode snapshot auf /sicher einen divx5 rip erstellen wollte. -> segfault xvid oder andere Ausgabeplugins von Transcode (inkl. divx4) auf /sicher kein Problem. divx5 auf reiserfs -> kein Problem. Bis ich soweit war das es am Dateisystem liegen könnte waren ca. 8 Stunden rum, sämtliche READMEs der beteiligten Programme gelesen, die multimedia-lib "auf links" gezogen und das mit dem filesystem ergab sich trotzdem nur zufällig als ich aus versehen im transcode im "falschen" Verzeichnis aufrief. Na ja, geschadet hat es sicher nicht, wenn man mal vom Gemaule meiner Frau absieht ;). -- :wq-y Maik
Hy, Am 02/05/04@09:31 schrieb Maik Holtkamp:
Der vfat Treiber muss noch irgendwelchen anderen Probleme haben. Drauf gestoßen war ich eigenlich als ich gestern mit dem letzten transcode snapshot auf /sicher einen divx5 rip erstellen wollte.
-> segfault
Nur der Vollständigkeit halber und fürs Archiv: Es liegt am divx5 codec. Der bringt bei vfat Partitionen seine MS Codebasis ins Spiel und erstellt in $HOME die Datei c:\trace_b.txt zu erstellen. Da der freware code eh keine b-frames unterstützt und wahrscheinlich seie log Datei nicht unter /home/maik bei vfat suchen wird, stürtzt das Teil einfach ab. -- :wq-y Maik
Hy, Am 02/05/04@14:00 schrieb Maik Holtkamp:
Am 02/05/04@09:31 schrieb Maik Holtkamp:
Der vfat Treiber muss noch irgendwelchen anderen Probleme haben. Drauf gestoßen war ich eigenlich als ich gestern mit dem letzten transcode snapshot auf /sicher einen divx5 rip erstellen wollte.
-> segfault
Nur der Vollständigkeit halber und fürs Archiv:
Gleicher Zweck ;)
Es liegt am divx5 codec. [...] Codebasis ins Spiel und erstellt in $HOME die Datei c:\trace_b.txt zu erstellen.
Es hilft die /usr/local/lib/libdivxencore.so mit vim -b zu bearbeiten. Darin nach c:\trace_b.txt suchen und den string durch z.B. 12345678901234 (wichtig auch 14 Stellen) zu ersetzen. Sollte auch die Probleme die divx5 mit mencoder hat beseitigen. -- :wq-y Maik
participants (2)
-
David Haller -
Maik Holtkamp