PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : OpenOffice öffnet Dateien nur schreibgeschützt, seid Umstellung auf NFS4



AndreasMeier
20.11.09, 12:36
Hallo zusammen,

ich hab heute meinen Server auf NFS4 umgestellt. Kann auch auf die Shares zugreifen und Dateien schreiben.

Jetzt hab ich aber bemerkt, dass OpenOffice Dateien von dem NFS-Share nur schreibgeschützt öffnet.
Alle gefundenen Lösungsansätze im Netz beziehen sich auf die alte OpenOffice- oder NFS-Version.

Im Zuge der NFS4-Umstellung läuft jetzt auch ein Idmapd.
Kann das damit zusammen hängen?

Wie kann ich OpenOffice so konfigurieren, dass ich Dateien wieder normal öffnen kann?

Danke und Gruß
Andreas

AndreasMeier
21.11.09, 09:16
Wenn ich das Verzeichnis über SSHFS mounte, kann ich Dateien ohne Schreibschutz öffnen.

Ich denk nach wie vor, dass das Problem bei NFS was mit "File-Locking" zu tun hat.
Hatte ich bei OpenOffice version1 und version2 anfangs in Zusammenhang mit NFS3 auch schon.
Damals hat die Auskommentierung im Startskript von OO ausgereicht, was es jetzt nicht tut.

Über SSHFS scheint mir das File-Locking zu funktionieren.

Kann das Problem bei NFS4 was mit User-IDs zu tun haben?
Ich hatte auch irgendwo gelesen, dass auf beiden Seiten (Server und Client) irgendein Dienst in Richtung "RPC" laufen muss. Das würde ja der "idmapd (http://linux.die.net/man/8/idmapd)" am Server übernehmen.
Brauch ich den Dienst dann auch auf dem Client?

Huhn Hur Tu
21.11.09, 12:55
Falsche Freigaberechte!
poste mal deine /etc/exports

Gruss STefan

AndreasMeier
21.11.09, 17:46
Hallo Stefan,

meinst Du?
Ich weiß in der Tat nicht genau, ob alles schon richtig eingestellt ist, hab auf NFS4 erst am Freitag umgestellt. Die Einträge hatte ich aus einer NFS4-Howto (https://help.ubuntu.com/community/NFSv4Howto).

Hier mal meine /etc/exports:


/nfs4exports 192.168.0.0/255.255.255.0(ro,sync,insecure,no_subtree_check,fs id=0)
/nfs4exports/raid 192.168.0.0/255.255.255.0(no_subtree_check,rw,nohide)


Gruß
Andreas

PS: ich versteh bloß nicht, warum dann (wenn es sich um fehlerhafte Freigabe handelt) die normalen Schreibrechte mit anderen Anwendungen funktionieren, sprich wenn ich z.B. mit nem Texteditor (Kate etc.) direkt am NFS-Share arbeite. Da kann ich ja auch direkt speichern.

Huhn Hur Tu
21.11.09, 18:59
Probiers mal mit



rw,fsid=0,insecure,no_subtree_check,async
statt

no_subtree_check,rw,nohide


Gruss Stefan

AndreasMeier
23.11.09, 07:58
Ok, hab jetzt umgestellt und neu gestartet.

Allerdings kann ich jetzt nicht mehr am Clients das Laufwerk per NFS4 verbinden.
Ich erhalte am Server die Fehlermeldung bzw. die Frage, ob der Idmapd gestartet ist.

Ich bin dann unter /usr/sbin/ gegangen und hab versucht, den Idmapd manuell auf der Konsole zu starten.
Dann erhalte ich die Meldung:


rpc.idmapd: Could not find group "nobody"

User und Group stehen in der /etc/idmapd.conf.

User = nobody
Group = nogroup

Beides ist im System angelegt, User "nobody" hat als primäre Gruppe "nogroup" eingetragen.
Allerdings sehe ich unter der Gruppe "nogroup" den User "nobody" nicht eingetragen. Ein bisschen merkwürdig.

Was ich auch merkwürdig finde, ist die Fehlermeldung:
Er meckert ja die Gruppe "nobody" an. Die gibt es in der Tat nicht, ist aber in der Config auch nicht so eingetragen, da steht "nogroup".

Was kann ich jetzt weiter probieren?

Danke und Gruß
Andreas

Huhn Hur Tu
23.11.09, 08:34
Wie waers damit.


http://linux.die.net/man/5/exports
http://www.citi.umich.edu/projects/nfsv4/linux/using-nfsv4.html
http://wiki.archlinux.org/index.php/NFSv4

Gruss Stefan

AndreasMeier
23.11.09, 10:44
Hallo Stefan,

danke für die Links und Deine Hilfe.

Bin gerade dabei den letzten Link bei Archlinux durchzuschauen.

Frage: ich find auf meinem Client an dem ich grad sitz kein "rpcbind" und konnte auch noch nicht rausfinden, wo das mit drinsteckt.
Für NFS3 hatte ich die Pakete portmap und nfs-common (hier ist auch der idmapd enthalten) installiert. Reicht das oder brauch ich evtl. mehr?
Der Mountpoint "rpc_pipefs " ist sowohl am Server als auch auf dem Client gesetzt und aktiv.

Danke und Gruß
Andreas

AndreasMeier
23.11.09, 11:56
Also, nochmal Nachtrag:
Ich hab jetzt auf dem Server die Gruppe "nobody" angelegt, obwohl in der idmapd.conf die Gruppe "nogroup" drin steht.
Hiermit klappt dann der Neustart des idmapd ohne Fehlermeldungen.

Zusätzlich hab ich die /etc/exports bezüglich der Netzwerk-Angabe überarbeitet und gebe z.Z. nur die eine Client-IP an.

Dennoch kann ich das Share nicht mounten und erhalte immer die Fehlermeldung:


client:/usr/sbin# mount -t nfs4 192.168.200.2:/raid /home/andreas/raid
mount.nfs4: mounting 192.168.200.2:/raid failed, reason given by server:
No such file or directory

drcux
23.11.09, 11:58
"192.168.200.2:/raid" !="/nfs4exports/raid"

AndreasMeier
23.11.09, 13:45
Danke für den Hinweis, stimmt, aber auch hier:


client:/usr/sbin# mount -t nfs4 192.168.200.2:/nfs4exports/raid /home/andreas/raid
mount.nfs4: mounting 192.168.200.2:/nfs4exports/raid failed, reason given by server:
No such file or directory

AndreasMeier
23.11.09, 14:25
Kann ich irgendwie überprüfen, ob der Server wirklich was exportiert, und ob das alles so korrekt ist?

drcux
23.11.09, 14:48
# showmount -e server

AndreasMeier
23.11.09, 15:52
Ok, wunderbar, hier erhalte ich dann korrekterweise (Abfrage des Servers vom Client aus):


Export list for 192.168.200.2:
/nfs4exports 192.168.200.12
/nfs4exports/raid 192.168.200.12


Wenn ich allerdings anstatt der Server-IP den Server-Namen "server" abfrage, erhalte ich nen Fehler:


fsc:/usr/sbin# showmount -e server
clnt_create: RPC: Unknown host


Der Name "server" ist im BIND eingetragen, der am Server läuft.

Gibts für den NFS- und Idmap- (=RPC??) Dienst evtl. ein separates Log-File, wo die Mount-Versuche protokolliert werden?
Ich hab in /etc/idmapd.conf den folgenden Eintrag bereits geändert / hochgesetzt, in der Hoffnung, hieraus mehr Erkenntnisse zu erhalten:


Verbosity = 0
=>
Verbosity = 3

AndreasMeier
24.11.09, 07:55
Ich hab jetzt auf dem Server in /var/log/syslog folgenden Eintrag gefunden:


Nov 24 08:33:16 server rpc.idmapd[2017]: nfsdcb: authbuf=192.168.200.12 authtype=user
Nov 24 08:33:16 server rpc.idmapd[2017]: Server: (user) id "1000" -> name "andreas@home.int"
Nov 24 08:33:16 server rpc.idmapd[2017]: nfsdcb: authbuf=192.168.200.12 authtype=group
Nov 24 08:33:16 server rpc.idmapd[2017]: Server: (group) id "100" -> name "users@home.int"


Wenn ich auf dem Client den Mount-Befehl ausführe, erhalte ich ja o.g. Fehlermeldung.
Zusätzlich dazu finde ich in /var/log/syslog folgendes:


Nov 24 09:39:04 client rpc.idmapd[1165]: New client: 16
Nov 24 09:39:04 client rpc.idmapd[1165]: Opened /var/lib/nfs/rpc_pipefs/nfs/clnt16/idmap
Nov 24 09:39:04 client rpc.idmapd[1165]: New client: 17
Nov 24 09:39:04 client rpc.idmapd[1165]: Client 16: (user) name "andreas@home.int" -> id "1000"
Nov 24 09:39:04 client rpc.idmapd[1165]: Client 16: (group) name "users@home.int" -> id "100"
Nov 24 09:39:04 client rpc.idmapd[1165]: Stale client: 16
Nov 24 09:39:04 client rpc.idmapd[1165]: ^I-> closed /var/lib/nfs/rpc_pipefs/nfs/clnt16/idmap
Nov 24 09:39:04 client rpc.idmapd[1165]: Stale client: 17
Nov 24 09:39:04 client rpc.idmapd[1165]: ^I-> closed /var/lib/nfs/rpc_pipefs/nfs/clnt17/idmap



Uhrzeit passt in den genannten Log-Einträgen generell nicht zusammen; Server-Eintrag ist nur einmal zu finden, nicht bei jedem Client-Mount-Versuch.
Der Log-Eintrag vom Client taucht bei jedem Mount-Versuch auf.

Uhrzeit Server=>Client weicht um ca. 30 Sekunden ab. Ich weiß, dass ich hier noch Baustelle hab, muss aber erst suchen, da alle Stationen eigentlich per NTP synchronisiert werden.

Könnt ihr mir aus den Log-Einträgen evtl. nen Tipp geben?

Danke und Gruß
Andreas

AndreasMeier
26.11.09, 08:35
Ich habs bis jetzt immer noch nicht geschafft, über o.g. Meldungen hinaus zu kommen.

Hab keine Lust auf NFS3 zurück zu konfigurieren.

Hat einer von euch evtl. noch eine Idee?

Ist die Zeitabweichung von 30 Sekunden Server zu Client ein Problem, was das Mounten verhindert?

AndreasMeier
26.11.09, 09:49
Also, ich hab hier (http://forums.fedoraforum.org/showthread.php?t=164662) eine Lösung gefunden.

Ich kann das Laufwerk nun mounten. Das ging allerdings erst bzw. nur, wenn ich folgenden Mountbefehl eingesetzt habe:


mount -t nfs4 192.168.200.2:/ /home/andreas/raid


Wichtig dabei war, dass es hinter der NFS-Server-IP mit dem ":/" aufhört, also kein Unterverzeichnis mehr dahinter.

Danke und Gruß
Andreas

AndreasMeier
26.11.09, 10:42
Das einzige, was mir jetzt noch fehlt, ist das automatische Mounten des NFS-Laufwerks beim Client-Start.

Es soll allerdings so sein, dass das NFS-Laufwerk nicht zwingend beim Start vorhanden sein muss.

Dazu hab ich in der /etc/fstab des Clients:


192.168.200.2:/ /home/andreas/raid nfs4 bg,soft,intr,retry=2 0 2


bg = background
soft = er braucht es nicht zwingend

Leider klappt das nicht automatisch.

Welche Mount-Optionen habt ihr, um ein automatisches Mounten zu ermöglichen?

Danke und Gruß
Andreas