FAT32-Partition/OOo1.1.4: Speichern ist nicht möglich?

Michael Hoehne

5 Feb 2005 5 Feb '05

13:08

Hallo LIStige, ich habe ein interessantes Problem (SuSE9.2/KDE3.3.0 + alle Patches): Unter meinem Arbeitsverzeichnis (/home/michael) habe ich eine FAT32-Partition gemountet (/home/michael/projekte), in der ich Projekte für die Fira aufbewahre, die ich gelegentlich mit Windows bearbeiten muß. Ausserdem habe ich das OOo 1.1.4 installiert, _nicht_ die 1.1.3-Version, die Suse beigelegt hat. Es ist eine Netwerkinstallation. Mein Benutzerverzeichnis liegt unter /home/michael/Programme/OpenOffice114. Sobald ich mit OOo 1.1.4 versuche, dort eine vorhandene Datei mich "speichern" oder "speichern unter" zu überschreiben, bekomme ich die Fehlermeldung "Sicherungskopie konnte nicht erstellt werden". Wobei die Option "Sicherungskopie immer erstellen" ausgeschaltet ist. Das Problem tritt nur auf der eingebundenen FAT32-Partition auf, unter Reiser klappt das alles hervorragend. Dieses Problem haben offenbar auch einige andere OOo-Benutzer, ohne das bisher eine Lösung gefunden wurde. Mit Hilfe einiger Leute aus der OOo-Liste habe ich nun alle mount-Optionen und Zugriffsrechte abgeklappert, es scheint alles O.K. zu sein: Jeder Benutzer hat dort alle Rechte (u.a. umask=0000)! Zuletzt habe ich mich mit strace angefreundet (schönes Tool!!!) und das Problem dingfest gemacht (nochmals Dank an Marc Santhoff für die Hilfe zu später Stunde). Beim Speichern auf die Reiser-Partition im Arbeitsverzeichnis sieht das Protokoll so aus: 21:39:51 open("/home/michael/Faltblatt.sxw", O_RDONLY) = 23 21:39:51 open("/home/michael/Programme/OpenOffice114/user/backup/... ...Faltblatt0.sxw", O_WRONLY|O_CREAT, 0100644) = 24 21:39:51 mmap2(NULL, 5590, PROT_READ, MAP_PRIVATE, 23, 0) = 0x48f57000 ...[Rest spar ich mir] Beim Speichern auf die FAT-Partition hingegen so: 21:14:43 open("/home/michael/projekte/Faltblatt.sxw", O_RDONLY) = 23 21:14:43 open("/home/michael/Programme/OpenOffice114/user/backup/... ...Faltblatt0.sxw", O_WRONLY|O_CREAT, 0100777) = 27 21:14:43 mmap2(NULL, 5576, PROT_READ, MAP_PRIVATE, 23, 0) = -1 ... ...EPERM (Operation not permitted) Marc meinte dazu:

...

Oder es gibt einen echten Grund für deren Fehlschlagen ... um das auseinanderzuhalten könntest Du mal die MAilingliste u.ä. bei Suse dazu befragen, ob irgnedein mmap-bug bekannt ist. Kann aber sein, daß mmap auf einer FAT32-Partition nicht zulässig ist.

Hat einer von euch ggf. eine Ahnung, was da warum schief laufen könnte? Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/

Show replies by date

Thomas Janssen

5 Feb 5 Feb

15:04

Am Samstag, 5. Februar 2005 14:08 schrieb Michael Hoehne:

...

[.....] Sobald ich mit OOo 1.1.4 versuche, dort eine vorhandene Datei mich "speichern" oder "speichern unter" zu überschreiben, bekomme ich die Fehlermeldung "Sicherungskopie konnte nicht erstellt werden". Wobei die Option "Sicherungskopie immer erstellen" ausgeschaltet ist. Das Problem tritt nur auf der eingebundenen FAT32-Partition auf, unter Reiser klappt das alles hervorragend.

Das Problem besteht nur mit OOo ? Sprich kannst Du andere Files darauf speichern ?

...

Dieses Problem haben offenbar auch einige andere OOo-Benutzer, ohne das bisher eine Lösung gefunden wurde. Mit Hilfe einiger Leute aus der OOo-Liste habe ich nun alle mount-Optionen und Zugriffsrechte abgeklappert, es scheint alles O.K. zu sein: Jeder Benutzer hat dort alle Rechte (u.a. umask=0000)!

Zuletzt habe ich mich mit strace angefreundet (schönes Tool!!!) und das Problem dingfest gemacht (nochmals Dank an Marc Santhoff für die Hilfe zu später Stunde). Beim Speichern auf die Reiser-Partition im Arbeitsverzeichnis sieht das Protokoll so aus:

21:39:51 open("/home/michael/Faltblatt.sxw", O_RDONLY) = 23 21:39:51 open("/home/michael/Programme/OpenOffice114/user/backup/... ...Faltblatt0.sxw", O_WRONLY|O_CREAT, 0100644) = 24 21:39:51 ^^^^^^^ mmap2(NULL, 5590, PROT_READ, MAP_PRIVATE, 23, 0) = 0x48f57000 ...[Rest spar ich mir]

Beim Speichern auf die FAT-Partition hingegen so:

21:14:43 open("/home/michael/projekte/Faltblatt.sxw", O_RDONLY) = 23 21:14:43 open("/home/michael/Programme/OpenOffice114/user/backup/... ...Faltblatt0.sxw", O_WRONLY|O_CREAT, 0100777) = 27 21:14:43 ^^^^^^^ mmap2(NULL, 5576, PROT_READ, MAP_PRIVATE, 23, 0) = -1 ... ...EPERM (Operation not permitted)

Deutet das vielleicht auf Rechte hin, die Fat32 nicht versteht ? Maybe kann einer mehr dazu sagen. Gruss Thomas

Thomas Janssen

15:24

Sorry. Am Samstag, 5. Februar 2005 16:04 schrieb Thomas Janssen:

...

Am Samstag, 5. Februar 2005 14:08 schrieb Michael Hoehne:

...
[.....] Sobald ich mit OOo 1.1.4 versuche, dort eine vorhandene Datei mich "speichern" oder "speichern unter" zu überschreiben, bekomme ich die Fehlermeldung "Sicherungskopie konnte nicht erstellt werden". Wobei die Option "Sicherungskopie immer erstellen" ausgeschaltet ist. Das Problem tritt nur auf der eingebundenen FAT32-Partition auf, unter Reiser klappt das alles hervorragend.

Das Problem besteht nur mit OOo ? Sprich kannst Du andere Files darauf speichern ?

...
Dieses Problem haben offenbar auch einige andere OOo-Benutzer, ohne das bisher eine Lösung gefunden wurde. Mit Hilfe einiger Leute aus der OOo-Liste habe ich nun alle mount-Optionen und Zugriffsrechte abgeklappert, es scheint alles O.K. zu sein: Jeder Benutzer hat dort alle Rechte (u.a. umask=0000)!

Oh, da hat es ne Zeile verbeamt, da fehlt noch: Die entsprechende Zeile in der fstab sieht wie aus ?

...

...
Zuletzt habe ich mich mit strace angefreundet (schönes Tool!!!) und das Problem dingfest gemacht (nochmals Dank an Marc Santhoff für die Hilfe zu später Stunde). Beim Speichern auf die Reiser-Partition im Arbeitsverzeichnis sieht das Protokoll so aus:

21:39:51 open("/home/michael/Faltblatt.sxw", O_RDONLY) = 23 21:39:51 open("/home/michael/Programme/OpenOffice114/user/backup/... ...Faltblatt0.sxw", O_WRONLY|O_CREAT, 0100644) = 24 21:39:51

^^^^^^^

...
mmap2(NULL, 5590, PROT_READ, MAP_PRIVATE, 23, 0) = 0x48f57000 ...[Rest spar ich mir]

Beim Speichern auf die FAT-Partition hingegen so:

21:14:43 open("/home/michael/projekte/Faltblatt.sxw", O_RDONLY) = 23 21:14:43 open("/home/michael/Programme/OpenOffice114/user/backup/... ...Faltblatt0.sxw", O_WRONLY|O_CREAT, 0100777) = 27 21:14:43

^^^^^^^

...
mmap2(NULL, 5576, PROT_READ, MAP_PRIVATE, 23, 0) = -1 ... ...EPERM (Operation not permitted)

Deutet das vielleicht auf Rechte hin, die Fat32 nicht versteht ? Maybe kann einer mehr dazu sagen.

Gruss Thomas

Michael Hoehne

16:05

Am Samstag, 5. Februar 2005 16:24 schrieb Thomas Janssen:

...

Sorry.

Am Samstag, 5. Februar 2005 16:04 schrieb Thomas Janssen:

...
Am Samstag, 5. Februar 2005 14:08 schrieb Michael Hoehne:

...
[.....] Dieses Problem haben offenbar auch einige andere OOo-Benutzer, ohne das bisher eine Lösung gefunden wurde. Mit Hilfe einiger Leute aus der OOo-Liste habe ich nun alle mount-Optionen und Zugriffsrechte abgeklappert, es scheint alles O.K. zu sein: Jeder Benutzer hat dort alle Rechte (u.a. umask=0000)!

Oh, da hat es ne Zeile verbeamt, da fehlt noch: Die entsprechende Zeile in der fstab sieht wie aus ?

Mittlerweile (unter zu Hilfenahme _aller_ Optionen, die und im Laufe des Abend einfielen): /dev/hda10 /home/etesh/Work/wProjekte vfat ... ...auto,rw,exec,suid,users,uid=michael,gid=users,umask=0000 0 0 Wird auch alles per "stat" bestätigt. Ursprünglich war sie mal _bedeutend_ kürzer... ;-) Gruß, Michael p.s. Das es an den Rechten liegt, glaube ich mittlerweile nicht mehr. Mittlerweile haben 4 Leute alles probiert und getestet. Alle haben das Problem und keiner hatte bisher Erfolg. Aufruf: Wenn hier irgendjemand eine FAT32 unter seinem Home eingebunden haben sollte, bei dem das Speichern funktioniert, bitte unbedingt melden!!! -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/

Illuminatus＠t-online.de

16:48

Michael Hoehne schrieb:

...

Aufruf: Wenn hier irgendjemand eine FAT32 unter seinem Home eingebunden haben sollte, bei dem das Speichern funktioniert, bitte unbedingt melden!!!

Hi Michael, ich wieder ;) Habe ja schon in der OOo Liste kundgetan, dass es bei mir mit OOo 1.1.2 geht. Eben habe ich es auch mit OOo 1.9.74 probiert, geht auch. @all Zur Ergänzung, damit wir nicht nochmal alles durchkauen müssen ;) Die Möglichkeiten der Rechtevergabe beim mount sind IMHO alle schon durchprobiert. Hier ist, glaube ich, nun C Programmierwissen gefragt. Wie sich beim tracen herausstellte, kommt der crash beim Aufruf der function mmap2: 21:14:43 mmap2(NULL, 5576, PROT_READ, MAP_PRIVATE, 23, 0) = -1 ... ...EPERM (Operation not permitted) man mmap2 sagt: ------8<------ NAME mmap2 - map files or devices into memory SYNOPSIS #include #include _syscall6(void *, start, size_t, length, int, prot, int, flags, int, fd, off_t, pgoffset); void * mmap2(void *start, size_t length, int prot, int flags, int fd, off_t pgoffset); #endif DESCRIPTION The function mmap2 operates in exactly the same way as mmap(2), except that the final argument specifies the off set into the file in units of the system page size (instead of bytes). This enables applications that use a 32-bit off_t to map larger files (typically up to 2^44 bytes). ------8<------ Ich versteh nix von C, mir fällt dabei nur auf, dass in dem Aufruf pgoffset 0 ist. Hier die Frage an die C Programmierer: Ist das so korrekt? Wenn nein, was sollte da dann stehen? Oder andere Frage: Kann mmap2 mit vfat funktionieren? -- Gruss Bernd

Andreas Koenecke

19:03

* Samstag, 05. Februar 2005 um 17:05 (+0100) schrieb Michael Hoehne:

...

Aufruf: Wenn hier irgendjemand eine FAT32 unter seinem Home eingebunden haben sollte, bei dem das Speichern funktioniert, bitte unbedingt melden!!!

Bei mir funktioniert es. Ich habe allerdings eine SuSE 9.0 mit glibc-2.3.2. Falls du noch weitere Infos oder irgendwelche Test benötigst, sag' Bescheid. Gruß Andreas -- Andreas Könecke "Andreas Koenecke " PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --

David Haller

6 Feb 6 Feb

01:17

Hallo, Am Sat, 05 Feb 2005, Andreas Koenecke schrieb:

...

* Samstag, 05. Februar 2005 um 17:05 (+0100) schrieb Michael Hoehne:

...
Aufruf: Wenn hier irgendjemand eine FAT32 unter seinem Home eingebunden haben sollte, bei dem das Speichern funktioniert, bitte unbedingt melden!!!

Bei mir funktioniert es. Ich habe allerdings eine SuSE 9.0 mit glibc-2.3.2. Falls du noch weitere Infos oder irgendwelche Test benötigst, sag' Bescheid.

Kannst du auch mal ein strace/ltrace (ltrace -S) laufen lassen, ich denke es liegt am MAP_PRIVATE, bzw. der Implementation von mmap2. ISTR, dass das auch schon mit StarOffice 4.x ein Problem war, da die Rechtevergabe auf vfat einfach zu mager ist. -dnh -- In /etc steht, was Du denkst. In /proc steht, was das OS denkt. [Thomas Blum in doc]

Andreas Koenecke

7 Feb 7 Feb

01:38

* Sonntag, 06. Februar 2005 um 02:17 (+0100) schrieb David Haller: (^^^^^ Uhr verstellt?)

...

Am Sat, 05 Feb 2005, Andreas Koenecke schrieb:

...
Bei mir funktioniert es. Ich habe allerdings eine SuSE 9.0 mit glibc-2.3.2.

Kannst du auch mal ein strace/ltrace (ltrace -S) laufen lassen, ich denke es liegt am MAP_PRIVATE, bzw. der Implementation von mmap2.

OK, das habe ich gemacht, aber anders als beim OP kann ich bei mir kein mmap2-Aufruf direkt nach einem "open(<Dateiname>...)" finden, noch nicht einmal in "der näheren Umgebung". Aber vielleicht ist es einfach nur zu spät... Ich habe den Trace der gesamten Sitzung (OOo starten mit Dateinamen, abspeichern auf VFAT und beenden) mal unter "http://www.andreas-koenecke.de/suse/oootrace.txt" abgelegt (ca. 1,8 MB). Dateiname: "Einspritzung1.sxw" VFAT-Verzeichnis: "/dev/hda1 on /home/akoenecke/wintest type vfat\ (rw,gid=100,umask=0002)" Gruß Andreas -- Andreas Könecke "Andreas Koenecke " PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --

Michael Hoehne

09:02

Am Montag, 7. Februar 2005 02:38 schrieb Andreas Koenecke:

...

* Sonntag, 06. Februar 2005 um 02:17 (+0100) schrieb David Haller: (^^^^^ Uhr verstellt?)

...
Am Sat, 05 Feb 2005, Andreas Koenecke schrieb:

...
Bei mir funktioniert es. Ich habe allerdings eine SuSE 9.0 mit glibc-2.3.2.

Kannst du auch mal ein strace/ltrace (ltrace -S) laufen lassen, ich denke es liegt am MAP_PRIVATE, bzw. der Implementation von mmap2.

OK, das habe ich gemacht, aber anders als beim OP kann ich bei mir kein mmap2-Aufruf direkt nach einem "open(<Dateiname>...)" finden, noch nicht einmal in "der näheren Umgebung".

Ich habe nur schnell drüber geschaut, aber auch nix gefunden. Hattest du auch daran gedacht, die Datei unter VFAT zu _überschreiben_? Das Speichern selber war ja nicht das Problem, sondern das Speichern bein schon vorhandenem Namen? Andererseits: Das Problem ist ja nun gelöst (s. mein Posting) weiter unten. Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/

Andreas Koenecke

12:35

* Montag, 07. Februar 2005 um 10:02 (+0100) schrieb Michael Hoehne:

...

Am Montag, 7. Februar 2005 02:38 schrieb Andreas Koenecke:

...
OK, das habe ich gemacht, aber anders als beim OP kann ich bei mir kein mmap2-Aufruf direkt nach einem "open(<Dateiname>...)" finden, noch nicht einmal in "der näheren Umgebung".

Ich habe nur schnell drüber geschaut, aber auch nix gefunden. Hattest du auch daran gedacht, die Datei unter VFAT zu _überschreiben_? Das Speichern selber war ja nicht das Problem, sondern das Speichern bein schon vorhandenem Namen?

Oops, ich wollte besonders smart sein und habe die alte Datei vorher extra gelöscht um das Tracelog klein zu halten... Der Vollständigkeit halber hier die entsprechenden Zeilen beim Überschreiben: ----------------- schnipp -------------------- open("/home/akoenecke/wintest/Einspritzung1.sxw", O_RDONLY) = 30 open("/home/akoenecke/OpenOffice.org1.1.4/user/backup/Einspritzung10.sxw",\ O_WRONLY|O_CREAT, 0100775) = 31 mmap2(NULL, 11154, PROT_READ, MAP_PRIVATE, 30, 0) = 0x4984a000 write(31, "PK\3\4\24\0\0\0\0\0\215\5G2\341\24519\36\0\0\0\36\0\0\0"..., 11154)\ = 11154 munmap(0x4984a000, 11154) = 0 fsync(31) = 0 close(30) = 0 close(31) = 0 ----------------- schnapp --------------------- (Das vollständige Tracelog liegt unter "http://www.andreas-koenecke.de/suse/oootrace2.txt".)

...

Andererseits: Das Problem ist ja nun gelöst (s. mein Posting) weiter unten.

Hm, ich kann hier auch überschreiben, wenn das vfat-Verzeichnis "noexec" gemountet ist. Gruß Andreas -- Andreas Könecke "Andreas Koenecke " PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --

Ruediger Meier

5 Feb 5 Feb

19:21

On Saturday 05 February 2005 17:05, Michael Hoehne wrote:

...

Aufruf: Wenn hier irgendjemand eine FAT32 unter seinem Home eingebunden haben sollte, bei dem das Speichern funktioniert, bitte unbedingt melden!!!

Bei mir klappts auf SuSE 9.1 OpenOffice_org-1.1.1-20 $ mount |grep fat /dev/hda1 on /windows type vfat (rw,noexec,nosuid,nodev,gid=100,umask=0002,iocharset=utf8) cu Ruediger

Ralf Schuchardt

6 Feb 6 Feb

21:33

On Sat, 5 Feb 2005 17:05:22 +0100 "Michael Hoehne" wrote:

...

Am Samstag, 5. Februar 2005 16:24 schrieb Thomas Janssen:

...
Sorry.

Am Samstag, 5. Februar 2005 16:04 schrieb Thomas Janssen:

...
Am Samstag, 5. Februar 2005 14:08 schrieb Michael Hoehne:

...
[.....] Dieses Problem haben offenbar auch einige andere OOo-Benutzer, ohne das bisher eine Lösung gefunden wurde. Mit Hilfe einiger Leute aus der OOo-Liste habe ich nun alle mount-Optionen und Zugriffsrechte abgeklappert, es scheint alles O.K. zu sein: Jeder Benutzer hat dort alle Rechte (u.a. umask=0000)!

Oh, da hat es ne Zeile verbeamt, da fehlt noch: Die entsprechende Zeile in der fstab sieht wie aus ?

Mittlerweile (unter zu Hilfenahme _aller_ Optionen, die und im Laufe des Abend einfielen):

/dev/hda10 /home/etesh/Work/wProjekte vfat ... ...auto,rw,exec,suid,users,uid=michael,gid=users,umask=0000 0 0

Wird auch alles per "stat" bestätigt.

Offenbar gibts da doch ein paar Probleme im Dateisystem mit den Rechten. Ein Schuss ins blaue: vertausche mal "users" und "exec". Von: http://groups.google.de/groups?q=mmap+fat+linux&hl=de&lr=&ie=UTF-8&scoring=d&selm=pan.2005.01.25.20.17.36.775649%40SpaMvodafone.es&rnum=3 ">> /dev/hda4 /data vfat exec,iocharset=utf8,users,gid=users,umask=000200

...

I'm not sure you can use 'exec,users'. Can you swap them, so you have 'users,exec,iocharset=utf8,gid=users,umask=0002' ? mount manpage says that you can override users's noexec by SUBSEQUENT exec..."

Aus der Mount-Man-Page: users Allow every user to mount and unmount the file system. This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line users,exec,dev,suid). Ich kanns leider hier nicht testen, aber vielleicht hilfts. Viele Grüße Ralf

Michael Hoehne

7 Feb 7 Feb

00:45

Am Sonntag, 6. Februar 2005 22:33 schrieb Ralf Schuchardt:

...

"Michael Hoehne" wrote:

...
Am Samstag, 5. Februar 2005 16:24 schrieb Thomas Janssen:

...
Am Samstag, 5. Februar 2005 16:04 schrieb Thomas Janssen:

...
Am Samstag, 5. Februar 2005 14:08 schrieb Michael Hoehne:

...
[.....] Dieses Problem haben offenbar auch einige andere OOo-Benutzer, ohne das bisher eine Lösung gefunden wurde. Mit Hilfe einiger Leute aus der OOo-Liste habe ich nun alle mount-Optionen und Zugriffsrechte abgeklappert, es scheint alles O.K. zu sein: Jeder Benutzer hat dort alle Rechte (u.a. umask=0000)!

...

Offenbar gibts da doch ein paar Probleme im Dateisystem mit den Rechten. Ein Schuss ins blaue: vertausche mal "users" und "exec".

Von: ... Aus der Mount-Man-Page: ...

Kann ich morgen früh mal au ausprobieren. Ich glaube allerdings noch nicht ganz daran, dass exec überhaupt benötigt wird... Aber gut, man weiß ja nie ;-) Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/

Michael Hoehne

01:06

New subject: GELOEST: Re: FAT32-Partition/OOo1.1.4: Speichern ist nicht möglich?

Am Sonntag, 6. Februar 2005 22:33 schrieb Ralf Schuchardt: Hallo Ralf,

...

Offenbar gibts da doch ein paar Probleme im Dateisystem mit den Rechten. Ein Schuss ins blaue: vertausche mal "users" und "exec".

ich konnte es doch nicht lassen und habe es gleich ausprobiert: Du hast gut geschossen! Sozusagen Blattschuss! Ich habe die Reihenfolge in "users,exec,..." geändert: Es klappt! Zurück zu "exec, users,..." und das problem taucht wieder auf... Halten wir also fest: Es müssen beide Optionen in der fstab stehen und sie müssen die von dir genannte Reihenfolge haben! Besten dank an dich und alle anderen, die versucht haben zu helfen! Ich werde dich auf der OOo-List zitieren, die suchen schon länger nach der Lösung. Nochmals danke, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/

Illuminatus＠t-online.de

09:39

New subject: GELOEST: Re: FAT32-Partition/OOo1.1.4: Speichern ist nicht möglich?

Michael Hoehne schrieb:

...

Am Sonntag, 6. Februar 2005 22:33 schrieb Ralf Schuchardt:

Hallo Ralf,

...
Offenbar gibts da doch ein paar Probleme im Dateisystem mit den Rechten. Ein Schuss ins blaue: vertausche mal "users" und "exec".

ich konnte es doch nicht lassen und habe es gleich ausprobiert: Du hast gut geschossen! Sozusagen Blattschuss!

Ich habe die Reihenfolge in "users,exec,..." geändert: Es klappt! Zurück zu "exec, users,..." und das problem taucht wieder auf...

Halten wir also fest: Es müssen beide Optionen in der fstab stehen und sie müssen die von dir genannte Reihenfolge haben!

*g* Seltsam, bei mir spielt das alles keine Rolle. -----8<----- # mount E # mount [...] /dev/hda6 on /windows/E type vfat (rw,uid=500,gid=100,umask=0000) # ls -l E insgesamt 222 drwxrwxrwx 10 bernd users 1024 1970-01-01 01:00 . drwxr-xr-x 5 root root 192 2005-01-15 11:17 .. [...] -rwxrwxrwx 1 bernd users 5361 2005-02-07 10:08 testvfat.sxw # umount E # ls -l E insgesamt 0 dr--r--r-- 2 root root 80 2005-02-07 09:44 . drwxr-xr-x 5 root root 192 2005-01-15 11:17 .. -----8<------ Du schriebst ja, dass andere Anwendungen keine Probleme mit dem Mountpoint hatten. OOo ist da wohl anspruchsvoller was die Rechte angeht. Oder macht mein mount da was anderes als Deiner? # mount -V mount: mount-2.12 -- Gruss Bernd

Michael Hoehne

11:31

New subject: GELOEST: Re: FAT32-Partition/OOo1.1.4: Speichern ist nicht möglich?

Am Montag, 7. Februar 2005 10:39 schrieb Bernd Obermayr:

...

Michael Hoehne schrieb:

...

*g* Seltsam, bei mir spielt das alles keine Rolle.

...

...

...

Oder macht mein mount da was anderes als Deiner?

Keine Ahnung. Könnte sein, das das alles an "users" hängt, das ich bisher verwendet habe. Das impliziert "noexec", das ich mit der Option "exec" wieder ausbügeln muß, weil OOo sonst nicht mag. Wenn ich heute abend nichts besseres vorhabe, dann werde ich mal "umbauen" und die Platte beim Start automatisch einbinden lassen. Ich nehme das "users" dann mal raus und schaue was passiert ;-)

...

# mount -V mount: mount-2.12

Hier mount-2.12c Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/

Michael Hoehne

5 Feb 5 Feb

15:58

Am Samstag, 5. Februar 2005 16:04 schrieb Thomas Janssen:

...

Am Samstag, 5. Februar 2005 14:08 schrieb Michael Hoehne:

...
[.....] Sobald ich mit OOo 1.1.4 versuche, dort eine vorhandene Datei mich "speichern" oder "speichern unter" zu überschreiben, bekomme ich die Fehlermeldung "Sicherungskopie konnte nicht erstellt werden". Wobei die Option "Sicherungskopie immer erstellen" ausgeschaltet ist. Das Problem tritt nur auf der eingebundenen FAT32-Partition auf, unter Reiser klappt das alles hervorragend.

Das Problem besteht nur mit OOo ? Sprich kannst Du andere Files darauf speichern ?

Ja, alle anderen Programme können problemlos speichern.

...

... Deutet das vielleicht auf Rechte hin, die Fat32 nicht versteht ? Maybe kann einer mehr dazu sagen.

Ist zu vermuten... Allerdings sollten die Rechtebeschreibungen ja durch UMASK ge"faked" werden. Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/

7024

Age (days ago)

7026

Last active (days ago)

List overview

Download

16 comments

7 participants

participants (7)

Andreas Koenecke
David Haller
Illuminatus＠t-online.de
Michael Hoehne
Ralf Schuchardt
Ruediger Meier
Thomas Janssen