![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
Hi 
On Kubuntu 14.04 with LibreOffice 4.2.4
I can open files that are on the desktop machine i am sitting in front of
but when i try to open files that are "on the network" i just get the
little splash-screen and progress-bar but then LO crashes.
Hmm, KDE is a bit different from what i am used to so i'm still hunting for
LO's User Profile and also wondering if i should uninstall LO and download
the proper one from our mad downloads page
Regards from
Tom
Hi
Err, i just tried renaming the user-profile and it had no effect.
Regards from
Tom
Could it be the way kubuntu has mounted the network drive.
In KDE Opensuse I can open local network files ok and can open files on our work server over the internet via Dolphin and sftp.
Steve
Hi again, are you opening from the LO file menu or clicking on the file in Dolphin.
Steve
Hi
Ahh, i tried both ways but i think both go through Dolphin don't they?
I've used Dolphin on non-KDE when Nautilus let me down with network-shares
on a different network and it worked a treat then. I didn't think of
trying a different file-browser. Konqueror is another good KDE one isn't
it?
I am not sure how the network drive has been mounted. It has just occurred
to me that i didn't try opening any other types of files over the network
before leaving the office.
I'm at home now and ssh'd into the company network so i can reinstall
LibreOffice remotely and i'd already torrented both "Fresh" and "Still" so
i have got choices wrt that.
Thanks for the hints! Gives me things to try :))
Regards from
Tom
Hi
I have tried a different file-browser and still same problems. Other types
of files that are on the network opened fine so it's only when trying to
open them in LibreOffice that there is a problem. A different machine with
Ubuntu on it opens the same files just fine so it's something between
Kubuntu and LibreOffice.
Things i have not tried yet is installing the untweaked version of LO
directly from the official website. I have tried the one in the default
repos and the one in the ppa. Also Steve Edmonds gave me some links to the
archives and i've not worked through any of those yet.
So, still got some things to try but wondering if anyone has a quick&easy
fix
Regards from
Tom
Hi Tom,
I can confirm this.
We have the same issue here at our office. Files opened from LO that are
located on our NAS or other network shares will not open properly. Local
copies of the same file do open without any trouble whatsoever.
Suggesting it is not something in the files themselves. Moreover it
happens with all files, not just specific LO files.
This is on Debian Jessie systems with different versions of LO in them.
Both native versions, installed through aptitude, and manually installed
versions. Versions vary between 4.0 and 4.3. Don't know if it already
happened before 4.0. The shares are hosted on NASses (how do you spell
this correctly?) from Synology and IOmega, but also on a Samba host. I
don't have a Windows system available, so I have not tested whether it
also happens on those shares, but I suspect it will. All in all it makes
me think the problem might be in LO itself. Not sure though.
P.S. To be honest, I have neglected til now to file a bug-report for
this. Should have done so, but somehow I never did.
Grx HdV
Hi,
P.S. To be honest, I have neglected til now to file a bug-report for
this. Should have done so, but somehow I never did.
There have already been several bug reports about this.
Alex
Hi
Hm, but Ubuntu has no troubles with network files. I thought i was on LO
3.5.7 but i might have upgraded. I'm out of the office for a few hours
again but could check later.
Our file-server is a Debian one and done using a Samba share. No other
files are affected so it's only when using LO to open them.
I've not tried using AbiWord but from what Alex is saying i suspect it is
only LO and maybe only certain versions. I've still not tried Steve's
links but hopefully might try those later. Thanks HdV for confirming!
I thought i had just done somethign weird when installing Kubuntu.
Regards from
Tom
Some additional data I just received from one of the colleagues. This
problem also appeared on Windows 7 and 8 clients. But one of the more
technically versed persons thought it might have to do with the quality
of the network connection. That was because using the same laptop and
NAS but connected to another WLAN he did not have these problems. That
first network is indeed not constant in speed and sometimes slows down
to a crawl (although it doesn't lose its connection altogether). He
thought (but has not confirmed) that these problems were appearing
mostly when that network was playing up. Maybe that information is of
use to those trying to solve this.
Grx HdV
Hi
It could easily be a network problem. I'm not convinced our network is
working as it should but various people have tested it and said it's fine.
Caligra opened the network files with no problem. Refused to open them
from the
File - Open
claiming that only local files could be opened. However when i went to the
network share and double-clicked on the file it opened just fine in Caligra
Author
Still got to read through some of those links that Steve sent me on Friday
Many thanks! Good luck and regards from
Tom
Hi Tom,
Same here. Other applications don't seem to have this problem at the
same moment LO does show them. Therfore I don't think it will be the
network itself. But maybe LO uses a component that is sensitive to a
less than stellar network performance when opening files over the
network. However that is only guessing and not based on any form of
decent testing.
Grx HdV
> Hi
> Hm, but Ubuntu has no troubles with network files. I thought i
> was on LO 3.5.7 but i might have upgraded. I'm out of the office
> for a few hours again but could check later.
>
> Our file-server is a Debian one and done using a Samba share. No
> other files are affected so it's only when using LO to open them.
>
[snip]
Some additional data I just received from one of the colleagues.
This problem also appeared on Windows 7 and 8 clients.
Funny this popped-up when it did. We just had a HelpDesk report,
last week, of a similar problem. .xls files that a user had been
opening for read for years all-of-a-sudden wouldn't open. Windows 7
and (if memory serves) MSO 2007. File modification dates indicated
they hadn't been modified in years. I tested it on my desktop (Ubuntu
13.x, IIRC) and LO would churn for a while, then emit a "something
wrong in the format/encoding/something" kind of an error and bail.
(Sorry for the useless error message info. I never bothered
recording it because I never believed it to be an LO problem.)
I copied the files to my local machine, using scp, and they opened
right up. I created a parallel directory on the server, copied the
files from the original directory into that, and they opened just
fine. I deleted the original directory and renamed the new one to the
original's name, and they opened just fine.
I'm suspecting a Samba screw-up (cached metadata?), on the server, in
my case.
But one of
the more technically versed persons thought it might have to do
with the quality of the network connection.
[snip]
Not in my case. Both the server in question and my desktop are
connected to the backbone switch with very short (less than 10m)
cable runs.
Regards,
Jim
Hi
Hm, but Ubuntu has no troubles with network files. I thought i
was on LO 3.5.7 but i might have upgraded. I'm out of the office
for a few hours again but could check later.Our file-server is a Debian one and done using a Samba share. No
other files are affected so it's only when using LO to open them.[snip]
Some additional data I just received from one of the colleagues.
This problem also appeared on Windows 7 and 8 clients.Funny this popped-up when it did. We just had a HelpDesk report,
last week, of a similar problem. .xls files that a user had been
opening for read for years all-of-a-sudden wouldn't open. Windows 7
and (if memory serves) MSO 2007. File modification dates indicated
they hadn't been modified in years. I tested it on my desktop (Ubuntu
13.x, IIRC) and LO would churn for a while, then emit a "something
wrong in the format/encoding/something" kind of an error and bail.
(Sorry for the useless error message info. I never bothered
recording it because I never believed it to be an LO problem.)I copied the files to my local machine, using scp, and they opened
right up. I created a parallel directory on the server, copied the
files from the original directory into that, and they opened just
fine. I deleted the original directory and renamed the new one to the
original's name, and they opened just fine.
Did you notice the permissions and owner on the server of the older files and newer ones. Did the permissions change when you copied the files. There is also a tick box in options>General to use LO open/save dialogue boxes. I don't know if that changes anything.
steve
[snip]
Did you notice the permissions and owner on the server of the older
files and newer ones. Did the permissions change when you copied
the files. There is also a tick box in options>General to use LO
open/save dialogue boxes. I don't know if that changes anything.
[snip]
The originals had owner execute permissions, whereas the copies did
not. The copies ended up with current modification dates.
Otherwise permissions and every other aspect of directory and files
were unchanged.
Regards,
Jim
[snip]
Did you notice the permissions and owner on the server of the older
files and newer ones. Did the permissions change when you copied
the files. There is also a tick box in options>General to use LO
open/save dialogue boxes. I don't know if that changes anything.[snip]
The originals had owner execute permissions, whereas the copies did
not. The copies ended up with current modification dates.
Otherwise permissions and every other aspect of directory and files
were unchanged.
Hi.
Some guff follows, but it would be interesting to see if the owner executable made a difference if its somehow got mixed in with DOS compatibility settings.
Another possibility might be to ask on the devs list how network file access in LO may differ from what you find is working for other files.
I have this vague recollection on our server 2 machines ago (older version samba) that I could open a LO file by double clicking in the file browser but not in the LO file open dialogue, or vice versa. Or may be it was I could open a file on a network share mounted locally but not by browsing the network. This all came right when I updated the server and started with cifs.
Steve
Note that there is no bit to specify that a file is executable. DOS and Windows NT filesystems identify executable files by giving them the extensions .EXE, .COM, .CMD, or .BAT.
Consequently, there is no use for any of the three Unix executable bits that are present on a file in a Samba disk share. DOS files, however, have their own attributes that need to be preserved when they are stored in a Unix environment: the archive, system, and hidden bits. Samba can preserve these bits by reusing the executable permission bits of the file on the Unix side - if it is instructed to do so. Mapping these bits, however, has an unfortunate side-effect: if a Windows user stores a file in a Samba share, and you view it on Unix with the |ls| |-al| command, some of the executable bits won't mean what you'd expect them to.
Three Samba options decide whether the bits are mapped: |map| |archive|,
map> >system |, and |map| |hidden|. These options map the archive,
system, and hidden attributes to the owner, group, and world execute bits of the file, respectively. You can add these options to the
[data]| share, setting each of their values as follows:
[data]
  path = /home/samba/data
  browseable = yes
  guest ok = yes
  writeable = yes
  map archive = yes
  map system = yes
  map hidden = yes
After that, try creating a file in the share under Unix - such as
hello.java| - and change the permissions of the file to 755. With these
Samba options set, you should be able to check the permissions on the Windows side and see that each of the three values has been checked in the Properties dialog box. What about the read-only attribute? By default, Samba 2.0 sets this whenever a file does not have the Unix owner write permission bit set. In other words, you can set this bit by changing the permissions of the file to 555.
We should warn you that the default value of the |map| |archive| option is |yes|, while the other two options have a default value of |no|. This is because many programs do not work properly if the archive bit is not stored correctly for DOS and Windows files. The system and hidden attributes, however, are not critical for a program's operation and are left to the discretion of the administrator.