Files auf nfs-share mit libreoffice öffnen klappt nicht

mr44er

mr44er

moderater Moderator
Teammitglied
Ich habe auf einem nfs-share diverse office-Dateien (doc,docx,xls,xlsx) liegen. Diese sollen mit libreoffice geöffnet werden. Öffne ich die Dateien direkt vom share, quittiert mir libreoffice das prompt mit den Meldungen wie im Bildanhang.

Die Dateien sind aber ok und wenn ich sie mir lokal auf die Platte kopiere, dann kann ich sie problemlos öffnen.

Ich hatte das Problem schonmal, weiß aber nicht mehr, wie ich es damals löste. Fixes googlen brachte mir in Erinnerung, dass es was mit dem file-locking war.

Code: 
mount -o nolock 10.0.8.1:/atank/privat /mnt/privat
mount_nfs: nmount: /mnt/privat, mount option <nolock> is unknown: Invalid argument

Ab da weiß ich nicht mehr weiter.
 

Anhänge

  • prob1.webp
    prob1.webp
    6,3 KB · Aufrufe: 526
  • prob2.webp
    prob2.webp
    6,6 KB · Aufrufe: 504
ich meine, es gibt da noch eine andere Möglichkeit - alledings braucht man auch hier root Rechte. Ändere die Datei /usr/local/bin/libreoffice und kommentiere die beiden Zeilen aus:

SAL_ENABLE_FILE_LOCKING=1
export SAL_ENABLE_FILE_LOCKING

Gruee, Norbert
 
@bsd4me

Danke dir, das funktioniert! Sehe ich als bessere Lösung an, als am nfs rumzufummeln. :)

Ich hab für meinen Fall noch einen anderen 'bequemen' Weg über die GUI gefunden.

Extras->Optionen->LibreOffice->Erweitert->Experteneinstellungen->UseDocumentSystemFileLocking->Suchen->auf false stellen->Ok->Ok

Es gibt noch 'UseDocumentOOoLockFile' und 'UseLocking' die man probieren kann. Fürs Archiv und google. :D

Rein interessehalber: file-locking ist in einer Netzumgebung ja gewünscht und eine gute Sache. Mein Verständnis: Zwei PCs haben Lese-/Schreibrechte auf eine Datei. Derjenige, der sie zuerst öffnet 'locked' die Datei und behält die Schreibrechte. Der zweite kann dann nur lesen, sonst ist die Konsistenz gefährdet, denn wenn PC1 eine Änderung reinschreibt und/oder diese auch noch speichert, wird auf PC2 ja nicht die Änderung 'live' übertragen.

Die Essenzfrage: Will man das bei libreoffice nicht oder ist das ein Bug oder falsch implementiert? Das gab es wohl schon mit openoffice und die ältesten Beiträge die ich fand waren von 2011.
 
Zuletzt bearbeitet:
das macht libreoffice doch auch so.
Also auch auf NFS-Shares, wenn die Berechtigung stimmt. Nur dann, wenn es nicht dort aktiv schreiben kann, also kein .lock.. erstellen kann oder darf, versagt der Mechanismus.
 
ja, bei mir hat es die eben auch (nicht auf allen Shares) und dort funktioniert es eben auch problemlos. Es gibt das .lock, die Datei öffnet sich und alles ist gut.
 
Werde das nochmal genau eruieren, wenn ich wieder vorort bin. Ist schließlich nicht das erste Mal, dass das Problem auftauchte.
 
Mal etwas ins Blaue geschossen: Sollte es nicht auch reichen, auf dem NFS-Server 'rpc.lockd' zu starten und auf dem Client ohne die 'nolockd' zu mounten? Denn ohne 'rpc.lockd' funktioniert zumindest der flock() Syscall nicht, den Libreoffice eventuell verwendet.
 
Das bekomme ich dann. ->erstes Bild im Anhang.

Erstelle ich eine neue Datei und will sie speichern, kommt der Fehler wie auf dem zweiten Bild.

nfsd und lockd habe ich danach neu gestartet, immer noch die gleichen Fehler.

Anhand vom Handbuch auf Server und Client die Dienste gestartet:
Code: 
Some applications require file locking to operate correctly.  To enable locking, add these lines to /etc/rc.conf on both the client and server:

rpc_lockd_enable="YES"
rpc_statd_enable="YES"
Code: 
If locking is not required on the server, the NFS client can be configured to lock locally by including -L when running mount.
Ohne rpc_lock und nur mit -L versucht, gibt wieder die alte Fehlermeldung.
 

Anhänge

  • Bildschirmfoto zu 2018-08-13 09-46-42.webp
    Bildschirmfoto zu 2018-08-13 09-46-42.webp
    13,7 KB · Aufrufe: 486
  • Bildschirmfoto zu 2018-08-13 09-56-57.webp
    Bildschirmfoto zu 2018-08-13 09-56-57.webp
    7,4 KB · Aufrufe: 475
Dann raten wir mal weiter. Nehme auf dem Server noch mal 'rpc.statd' hinzu, wenn du es noch nicht hast. Ohne den funktioniert die Familie der stat() Syscalls nicht, die Libeoffice eventuell nutzt um Lock-Dateien abzufragen. Danach haben wir dann aber auch alles zusammen, geht's dann nicht bin ich ahnungslos. :)
 
mr44er schrieb:
Extras->Optionen->LibreOffice->Erweitert->Experteneinstellungen->UseDocumentSystemFileLocking->Suchen->auf false stellen->Ok->Ok
Zum Vergrößern anklicken....

Das ist bisher mein 'elegantester' Weg, das sollte auch ein Update überleben. Kannst ja mal probieren und berichten...da muss die /usr/local/bin/soffice gar nicht angefasst werden. ;)

Das File-Locking ist im Moment nicht wirklich relevant, da ich der einzige User bin, aber wäre eben nice to have und die saubere Lösung.

@Yamagi

dmesg spuckte mir noch was hin, habe ich vorhin übersehen:
Code: 
NLM: failed to contact remote rpcbind, stat = 3, port = 28416
NLM: failed to contact remote rpcbind, stat = 3, port = 28416
Can't start NLM - unable to contact NSM
NLM: failed to contact remote rpcbind, stat = 3, port = 28416
NLM: failed to contact remote rpcbind, stat = 3, port = 28416
Can't start NLM - unable to contact NSM

Und hier mein Eintrag in der rc.conf nochmal zur Übersicht/Klarheit, ggf. hab ich das was falsch gemacht:

Code: 
###nfsserver###
nfs_server_enable="YES"
mountd_flags="-r"
rpcbind_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
###nfsserver###
 
Eigentlich nicht. Ich habe:
Code: 
nfs_server_enable="YES"
nfsv4_server_enable="YES"
nfs_client_enable="YES"
nfsuserd_enable="YES"
nfsuserd_flags="-domain home.yamagi.org"
nfscbd_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
Ich bin mit aber recht sicher, dass man zumindest 'nfsuserd' und 'nfscbd' nicht explizit starten muss. Die sollten in 'nfsv4' enthalten sein. Ich hab's nur gerne explizit. Ich kann heute Abend gerne mal schauen ob LibreOffice damit funktioniert.
 
Aber gerne doch, mach gemütlich, es eilt nicht. :) Vielleicht siehst du ja direkt die Problemlösung, wenn du das nachstellst.

Yamagi schrieb:
Die sollten in 'nfsv4' enthalten sein
Zum Vergrößern anklicken....
Siehste mal, das wäre auch was...ich kann dir gar nicht sagen, ob nfsv4 oder 3 gestartet wird, wenn man nichts angibt.

Edit: Gerade mal ein aktuelles Linux Mint als Client getestet. Da verhält sich das libreoffice auch so.
 
also, bei mir ist das NFS3 und ich habe:
Code: 
nfs_client_enable="YES"
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 24"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
rpcbind_enable="YES"
mountd_flags="-r"
Wobei ich mich nicht erinnere, was der letzte Eintrag macht.

Die .lock Dateien scheinen mir zu gehören. Also denke ich, dass ich auch die entsprechenden Rechte auf die Freigabe brauche. Versuch es doch mal mit einer Testfreigabe und chmod -R 777, nur, um sicher zu gehen.

Und ne andere, eher ganz unwahrscheinliche Idee: vielleicht mal aus einem anderen Dateimanager heraus öffnen.
 
Code: 
root@aserver:/atank/privat # ls -l | grep testfreigabe
drwxr-xr-x   2 mr44er  wheel    2 Aug 13 16:32 testfreigabe
root@aserver:/atank/privat # chmod -R 777 testfreigabe/
root@aserver:/atank/privat # ls -l | grep testfreigabe
drwxrwxrwx   2 mr44er  wheel    2 Aug 13 16:32 testfreigabe
root@aserver:/atank/privat # cd testfreigabe/
root@aserver:/atank/privat/testfreigabe # ls -l
total 1
-rw-r--r--  1 mr44er  wheel  79 Aug 13 16:34 .~lock.testfile.odt#   <--- Das ~lock-file bleibt bestehen, solange ich die Fehlermeldung noch stehenlasse.
-rw-r--r--  1 mr44er  wheel   0 Aug 13 16:34 testfile.odt

####ab hier habe ich die Fehlermeldung geklickt und libreoffice geschlossen###

root@aserver:/atank/privat/testfreigabe # ls -l
total 1
-rw-r--r--  1 mr44er  wheel  0 Aug 13 16:34 testfile.odt
root@aserver:/atank/privat/testfreigabe #

Habe den writer gestartet und die Datei habe ich in die Testfreigabe schreiben wollen.

Dh. hier war gar kein Dateimanager involviert. ;)
 

Anhänge

  • aktuell.webp
    aktuell.webp
    7,5 KB · Aufrufe: 479
ich deute die Fehlermeldung mal so, als ob jemand anders die Datei schon bearbeitet und die deshalb nicht gespeichert werden kann. Was ziemlich schräg ist, weil du offensichtlich die Datei besitzt und bearbeitetest.
Ich zeige mal den Ablauf bei mir, FreeBSD11.1 Client, FreeBSD7.4 mit NFS-V3 Server, wie oben gezeigt:
Das ist eine Datei auf der gemounteten Freigabe, dann mit lowriter hin navigiert und geöffnet, dann etwas verändert und gespeichert und dann geschlossen.
Code: 
root@Celsius:/home/pit # ll /mnt/files/raid1/pit/ods-odt/ | grep 50-50
-rw-r--r--  1 pit  operator     10566  8 Sep.  2016 50-50-50_2.ods
root@Celsius:/home/pit # ll /mnt/files/raid1/pit/ods-odt/ | grep 50-50
-rw-r--r--  1 pit  operator        77 13 Aug. 19:34 .~lock.50-50-50_2.ods#
-rw-r--r--  1 pit  operator     10566  8 Sep.  2016 50-50-50_2.ods
root@Celsius:/home/pit # ll /mnt/files/raid1/pit/ods-odt/ | grep 50-50
-rw-r--r--  1 pit  operator        77 13 Aug. 19:35 .~lock.50-50-50_2.ods#
-rw-r--r--  1 pit  operator     10574 13 Aug. 19:35 50-50-50_2.ods
root@Celsius:/home/pit # ll /mnt/files/raid1/pit/ods-odt/ | grep 50-50
-rw-r--r--  1 pit  operator     10524 13 Aug. 19:35 50-50-50_2.ods
 
pit234a schrieb:
ich deute die Fehlermeldung mal so, als ob jemand anders die Datei schon bearbeitet und die deshalb nicht gespeichert werden kann. Was ziemlich schräg ist, weil du offensichtlich die Datei besitzt und bearbeitetest.
Zum Vergrößern anklicken....
Jap, es gibt auch sonst niemanden, der drauf zugreifen könnte.

Die Berechtigungen sind ja gleich, allerdings sind Server und Client bei mir auf 11.2
Seltsame Sache das...:confused:
 
Hallo @pit234a

Mal ne Frage am Rande: Du hast aber nicht auf der gleichen Maschine sowohl Client als auch Server enabled?
Wenn ja, hat das einen besonderen Grund?
 
Jepp, Client und Server auf einer Kiste ist überhaupt kein Problem. Ohne würde hier das halbe Netz kollabieren. ;)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben