Hallo in die Runde,
Gerhard Weydt war so nett, dieses Problem in diese Runde zu posten. Bisher gibt es keinerlei Reaktion? Wie soll ich das verstehen? Ist das Problem schlecht beschrieben, zu kompliziert oder sollte es wirklich niemand geben, der dazu etwas sagen kann? Mich bewegt es schon längere Zeit und ich würde es gern "mal vom Tisch" kriegen.
Beste Grüße,
Peter
Hallo Peter,
Gerhard Weydt war so nett, dieses Problem in diese Runde zu posten.
Bisher gibt es keinerlei Reaktion? Wie soll ich das verstehen? Ist das
Problem schlecht beschrieben, zu kompliziert oder sollte es wirklich
niemand geben, der dazu etwas sagen kann? Mich bewegt es schon längere
Zeit und ich würde es gern "mal vom Tisch" kriegen.
Vielleicht gibt es einfach zu wenig Leute hier, die mit so einer
Kombination arbeiten. Ich z.B. speichere nur lokal und nutze auch sonst
kein NAS.
Gruß
Robert
Hallo Peter,
Bisher gibt es keinerlei Reaktion? Wie soll ich das verstehen? Ist
das Problem schlecht beschrieben, zu kompliziert oder sollte es
wirklich niemand geben, der dazu etwas sagen kann? Mich bewegt es
schon längere Zeit und ich würde es gern "mal vom Tisch" kriegen.
Ich kann erst einmal bestätigen, dass ich das gleiche Problem hätte,
wenn ich die Funktion nutzen würde, was ich aber nur für diese Test das
erste mal getan habe.
Aus deinen Info schließe ich, dass du sowohl unter Windows, als auch
unter Linux die Dateien der betreffenden Freigabe über einen direkten
(UNC-)Pfad ansprichst, also unter:
Windows: \\server\freigabe\...
Linux: smb://server/freigabe/...
Du schreibst ja, dass der Link im Dokument als "smb://..." gespeichert
wäre.
Leider heißt das ja nicht, das Linux und Windows hier auf die gleiche
Nomenklatur zurück greifen, sondern nur, dass sich die
LibreOffice-Macher für die Speicherung des Netzwerkpfades auf diese
Nomenklatur geeinigt haben… Das macht ja auch Sinn, da man die gleiche
Schreibweise für diverse andere Protokolle verwenden kann: ftp://… ,
http://…
Bei der Übergabe an das Windows-System, das mit dieser Angabe so gar
nicht anfangen kann, wird diese Angabe wohl in die dort übliche
UNC-Pfadangabe (\\...\...\...) gewandelt, während es bei Linux direkt
an den Desktop übergeben wird.
Unter Linux hingegen ist das SMB-Protokoll ja nicht nativ eingebaut, so
dass der Desktop entsprechende "Helfer" bemühen muss. Hier scheint dann
aber der Hund begraben zu sein:
Genau wie bei dir, bekomme ich Problemlos einen Link z.B. zu einer
Überschrift eines Dokumentes auf meinem NAS nur dann eingerichtet, wenn
ich den kompletten Pfad zum Dokument manuell vorgebe (hier:
smb://192.168.3.12/public/Test.odt).
Wenn ich hingegen mit dem sich öffnenden Dateiauswahlfenster zu der
Datei "navigiere", so scheitere ich! Selbst wenn ich die Eingabe per
Textzeile einschalte und den Pfad bis
smb://192.168.3.12/
oder gar bis
smb://192.168.3.12/public
vorgebe, bekomme ich eine Fehlermeldung, das dies kein Ordner wäre und
kann auch nicht weiter navigieren.
Das ganze auf einem Laptop mit xfce unter Ubuntu.
So wie es ausschaut, gibt es da ein Kommunikationsproblem zwischen LO
und dem Desktop, so dass LO keine als gültig interpretierbare Angabe
zum Dateipfad zurück geliefert bekommt.
Wenn man das häufiger braucht, ist der Fehler natürlich lästig.
Ich würde dir empfehlen wollen, den Netzwerkpfad durch das "Mounten" der
Freigabe zu vermeiden. So würdest du einfach zu einem Dokument
innerhalb des Dateibaums verlinken und das "smb://" als
Protokollangabe könnte entfallen. Aber dann hast du ein Problem bei den
Windows-Rechnern, bei denen das "Mounten" ja nur als "Netzlaufwerk" mit
"Laufwerksbuchstaben" vorgesehen ist. Damit bekommt man schwerlich
einen Dateipfad, der sowohl unter Linux als auch unter Windows
identisch ist...
Gruß,
Michael