[Linux] NTFS-Partition mounten
-
Hallo,
ich versuche gerade unter Linux (ubuntu 5,10) meine NTFS-Partition zu mounten.
Ich habe ein Terminal gestartet und dann mit sudo -s mich als root angemeldet.
Dann im Ordner /media einen Ordner win_e angelegt.
Mit "mount /dev/sda6 /media/win_e" habe ich dann das Verzeichnis "gemountet". Bin auch in diesem Terminal auf win_e draufgekommen (im "Datei-Browser" nicht - soweit klar, bin dort ja nicht root).Dann habe ich noch verschiedene Optionen (-O) ausprobiert.
Und zwar:
mount /dev/sda6 /media/win_e -O user,uid=oliver,gid=oliver,umask=000
Habe dort auch die ein oder andere Option weggelassen oder uid=1000 geschrieben. Egal was ich angebe ich komme nur im Terminal mit root-Rechten auf den Ordner. Im Internet habe ich das so gefunden und sollte ja eigentlich so gehen - oder?Wenn ich das in der Datei /etc/fstab eintrage und neu starte komme ich auch nur mit root-Rechten auf den Ordner.
/e: Habe dem Ordner win_e auch vor dem Mounten die Rechte 777 gegeben (danach geht nicht mehr da ich nur Leserechte auf dem Ordner habe).
Was mache ich falsch?
Vielen Dank!
-
welche rechte der ordner vor dem mounten hat, ist egal.
Ich mounte ntfs nur mit ro,umask=0 und da kann jeder lesen.
-
Von Linux aus, kann man NTFS IIRC nur vernünftig lesen, schreiben klappt, wenn überhaupt, miserabel.
-
mit diesem teil funzt auch der schreibzugriff sicher:
-
DrGreenthumb schrieb:
welche rechte der ordner vor dem mounten hat, ist egal.
Ich mounte ntfs nur mit ro,umask=0 und da kann jeder lesen.Das hatte ich auch versucht, komme nur als root auf den Ordner.
GPC schrieb:
Von Linux aus, kann man NTFS IIRC nur vernünftig lesen, schreiben klappt, wenn überhaupt, miserabel.
,
atomfish schrieb:
mit diesem teil funzt auch der schreibzugriff sicher:
Schreiben ist nicht so wichtig. Werde es mir aber mal ansehen.
-
DrGreenthumb schrieb:
welche rechte der ordner vor dem mounten hat, ist egal.
Ich mounte ntfs nur mit ro,umask=0 und da kann jeder lesen.Ohh
Habe das jetzt mal in /etc/fstab so reingeschrieben - es geht!!
Vielen Dank!Wundert mich jetzt aber das das nicht mit dem Befehl mount geht - aber reicht erstmal so.
-
atomfish schrieb:
mit diesem teil funzt auch der schreibzugriff sicher:
a) Läuft auf aktuellen Kerneln nicht mehr
b) Ist sau-sau-sau-sau-sau-langsam
c) War nur ein experimenteller Proof-Of-Concept
-
Sgt. Nukem schrieb:
a) Läuft auf aktuellen Kerneln nicht mehr
Nur solange, bis die FUSE-Version fertig ist.
b) Ist sau-sau-sau-sau-sau-langsam
Das liegt im wesentlichen an zwei Dingen:
- NTFS ist scheiße
- einige Distributoren haben kaputte Versionen mit Memleaks ausgeliefert, bei Fedora war das zB. der Fall, habe ich selbst erlebt.
c) War nur ein experimenteller Proof-Of-Concept
Wem plapperst Du das denn jetzt schon wieder nach?
Das war einfach ein Nebenprodukt von ReactOS. Weder experimentell, noch Proof-Of-Concept.
edit: blöde Listen
-
nman schrieb:
Sgt. Nukem schrieb:
a) Läuft auf aktuellen Kerneln nicht mehr
Nur solange, bis die FUSE-Version fertig ist.
Und in welchem Jahrtausend wird das sein?
BTW: Waren nicht _2_ veraltete Dinge notwendig?
nman schrieb:
b) Ist sau-sau-sau-sau-sau-langsam
Das liegt im wesentlichen an zwei Dingen:
- NTFS ist scheiße
- einige Distributoren haben kaputte Versionen mit Memleaks ausgeliefert, bei Fedora war das zB. der Fall, habe ich selbst erlebt.
NTFS ist doch saugeil!
Von den Memleaks wußt' ich nix. Hatte aber IIRC die online-Version.nman schrieb:
c) War nur ein experimenteller Proof-Of-Concept
Wem plapperst Du das denn jetzt schon wieder nach?
Das war einfach ein Nebenprodukt von ReactOS. Weder experimentell, noch Proof-Of-Concept.
Hmmm... ich meine mich daran erinnern zu können, daß der Autor das auf der Page schrieb. So als Grund warum er da keinen weiteren Input mehr reinsetzt und das verfaulen lässt. Ist aber schon was her...
-
Sgt. Nukem schrieb:
Und in welchem Jahrtausend wird das sein?
Keine Ahnung, interessiert halt auch niemanden so richtig, weil NTFS Write-Support nicht sehr interessant ist.
NTFS ist doch saugeil!
Klar, verglichen mit FAT32 schon, verglichen mit Reiser und anderen ernstzunehmenden Dateisystemen eher nicht.
Hmmm... ich meine mich daran erinnern zu können, daß der Autor das auf der Page schrieb. So als Grund warum er da keinen weiteren Input mehr reinsetzt und das verfaulen lässt. Ist aber schon was her...
Nein, das war ganz am Anfang, dann bekam Captive ein eigenes Entwicklerteam und das lässt jetzt verrotten, weil es featuremäßig alles kann, was es können sollte und sie jetzt an der FUSE-Version arbeiten. (Oder so ähnlich, ich lese deren Mailingliste nur sehr sporadisch.)
-
b) Ist sau-sau-sau-sau-sau-langsam
Das liegt im wesentlichen an zwei Dingen:
* NTFS ist scheiße
Warum ist es dann unter Windows schnell?
-
blödsinn schrieb:
Warum ist es dann unter Windows schnell?
NTFS ist auch unter Windows nicht schneller als zB reiserfs unter GNU/Linux.
Oder XFS. Oder ext3. Oder...
-
Es ging ja nicht um schneller sondern um sau-sau-sau-sau-sau-langsam.
-
blödsinn schrieb:
Es ging ja nicht um schneller sondern um sau-sau-sau-sau-sau-langsam.
Ich nannte ja auch zwei Gründe. Und der NTFS-ist-scheiße-Faktor trägt die Schuld an einem, maximal zwei "sau"s. Der Rest geht ganz klar auf die Kappe des Memleaks.
-
Woher bekommt man denn Reiser Treiber für Windows?
----------------------
:xmas1:
-
Gibt nur Zugreif-Tools, keinen IFS-Driver.
Aber auch von dem EXT2/3-IFS-Driver rate ich ab.
-
ROP schrieb:
Woher bekommt man denn Reiser Treiber für Windows?
ReiserFS funktioniert unter Windows nur suboptimal, aber wenn Du nur Daten auslesen möchtest, dann schau da mal durch:
http://p-nand-q.com/download/rfstool.html
http://yareg.akucom.de/
http://rfsd.sourceforge.net/
http://www.crossmeta.com/
-
ReiserFS funktioniert unter Windows nur suboptimal
Warum?
-
Grund? schrieb:
Warum?
Weil reiserfs ein Unix-Dateisystem ist. Keiner der Sponsoren oder Entwickler interessiert sich ernsthaft dafür, sowas unter Windows verfügbar oder besser verwendbar zu machen.
-
Dann sind die aber schön doof finde ich. Wenn es gut unter Windows funktioniert dann werden doch auch mehr Leute Linux als Zweitsystem installieren.