Bug 67527

Can not save or change .odb file over smb/nautilus mount, work fine in LO4.0.
It look like it is the same source problem you have.

Created attachment 83298 [details]
Can edit and save

Created attachment 83299 [details]
Can not edit or save

confirmed by comment #2 => NEW, regression as claimed to have worked with 4.0.x.

Can you test (maybe in a VM) if a later Ubuntu version (e.g. 13.04) still shows the issue? => NEEDINFO

My system is debian 7.1 (wheezy) amd64.

Bjoern - going to go ahead and mark this as NEW - as you've confirmed. I'll leave any further discussion to you and maiil@rittsel.com - seems like a nasty one so upping priority.

(In reply to comment #4)
> confirmed by comment #2 => NEW, regression as claimed to have worked with
> 4.0.x.
> 
> Can you test (maybe in a VM) if a later Ubuntu version (e.g. 13.04) still
> shows the issue? => NEEDINFO

Hi Björn,

I've installed 13.04 in a VM and funny enough it didn't work with the default installation of 4.0, however, I installed 4.1.0.4 through PPA for 13.04 (raring), and it works just fine!

I ran ps aux | grep libreoffice on both machines and they both show the same:

rittsel   2824  0.0  0.1 143728  3184 ?        Sl   04:46   0:00 /usr/lib/libreoffice/program/oosplash --writer /run/user/rittsel/gvfs/smb-share:server=XXXXX,share=bibliotek/Serverdrift/Backupunderlag.ods
rittsel   2845  0.7  3.0 808068 61496 ?        Dl   04:46   0:00 /usr/lib/libreoffice/program/soffice.bin --writer /run/user/rittsel/gvfs/smb-share:server=XXXXX,share=bibliotek/Serverdrift/Backupunderlag.ods --splash-pipe=6

Might this bug be similar to Bug 67675 & Bug 67769?

(In reply to comment #8)
> Might this bug be similar to Bug 67675 & Bug 67769?


Looks like it's exactly the same as 67675, but 67769 says it disappears after 10 seconds, that's not the case for me. I get the repair dialog, just as 67675.

I have the same problem

*** Bug 67675 has been marked as a duplicate of this bug. ***

*** Bug 67892 has been marked as a duplicate of this bug. ***

*** Bug 67769 has been marked as a duplicate of this bug. ***

Can confirm this issue on my machine with Ubuntu 12.04 with LO 4.1.0.4 from ppa:libreoffice/ppa . I can only open .odt or .odp files successfully either from a local folder or by going via ~/.gvfs/sharename/document.odt . Opening from the share in Nautilus triggers the repair dialog.

Here is a WORKAROUND:

For Nautilus users:
Open the .desktop file (such as /usr/share/applications/libreoffice4.1-writer.desktop for LO Writer) and comment the following line:
X-GIO-NoFuse=true

For Dolphin users:
Open the same file, and comment the following line:
X-KDE-Protocols=file,http,smb,ftp,webdav

I've made some testing of this bug, and it seems that it depends on distribution\packages-source combination, as follows:

What was tested:
----------------
1) Ubuntu 12.04.2, 13.04 (64-bit) with packages from PPA and packages from libreoffice.org
2) Fedora 19 (64-bit) with packages from repos and packages from libreoffice.org
3) Ubuntu 13.10 (64-bit) with packages from repos
LO 4.1.0.4 was used in all cases.

Reproduction steps:
-------------------
1) Double-click in Nautilus
-OR-
2) From CLI: libreoffice(4.1) --writer smb://ip_address/share_name/document.odt
Both methods always gave the same results. Each time I couldn't open the document, applying the workaround from comment 15 did the job.

Results:
--------
1) Cases when I got the repair dialog:
Ubuntu 12.04.2 + Packages from PPA

2) Cases when LO just closed immediately (just like in bug 67769):
Ubuntu 12.04.2 + Packages from libreoffice.org
Ubuntu 13.04 + Packages from libreoffice.org
Ubuntu 13.10 + Packages from repos
Fedora 19 + Packages from libreoffice.org

3) Cases when I couldn't reproduce the bug:
Fedora 19 + Packages from repos

4) Uncertain:
Ubuntu 13.04 + Packages from PPA (This one is really strange, as it works when double-clicking in Nautilus, but don't work from the CLI, unless you opened Nautilus and mounted the share before that.)

Just to correct some inaccuracy in my last comment: Fedora 19 + Packages from repos behave the same as Ubuntu 13.04 + Packages from PPA.

*** Bug 68119 has been marked as a duplicate of this bug. ***

Problem happens with me as well.  Fedora 18, x64, (KDE) LibreOffice 4.1, installed with rpm's from the LibreOffice site.  

Doubleclicking on any Libreoffice file from a SBM share in Dolphin browser, Libreoffice starts, if its not already running, and then I get the bouncing icon next to my mouse cursor for a little while, and then no document.  No obvious error, or anything, just no document.  Clicking on a plain text file, for example works fine.  LibreOffice 4.0 worked fine.


Work around in comment 15 also fixes problem. (so far with .xls files, Using Calc)

What I can reproduce on a Fedora 19 (x86_64) machine is as follows:

Installed a local samba server with
$ sudo yum install samba samba-client
$ sudo setsebool samba_enable_home_dirs on
$ sudo systemctl start smb.service
$ sudo smbpasswd -a "$USER"
first.

Then, used Nautilus "Connect to Server" to connect to smb://127.0.0.1/<USER>, and opened some *.odt file via double-click in the Fedora 19 distro LibreOffice (4.1.0), which worked as expected.

Then, used command line ".../soffice smb://127.0.0.1/"$USER"/...odt" to open that *.odt file in various LibreOffice versions:

It opened the document as expected in all those LibreOffice versions that are built with GIO support (the distro's LO 4.1.0, my own-built master).

But it failed to do anything and just silently returned with all those LibreOffice versions that are built with old GnomeVFS support (the LO 3.6, 4.0, 4.1 available from <http://www.libreoffice.org/download>).

So I created an own-built master with GnomeVFS rather than GIO support (--disable-gio --enable-gnome-vfs), which also failed to do anything, ultimately because the call to gnome_vfs_get_file_info in gvfs::Content::getInfo (ucb/source/ucp/gvfs/gvfs_content.cxx) failed with GNOME_VFS_ERROR_NOT_SUPPORTED.  The reason for that, in turn, was that package gnome-vfs2-smb was not installed on the machine.

That is, installing the Fedora 19 package gnome-vfs2-smb made the command line ".../soffice smb://127.0.0.1/"$USER"/...odt" work for all those cases for which it had previously failed, incl. the LO 3.6., 4.0, 4.1 available from <http://www.libreoffice.org/download>.

This likely explains comment 19 "No obvious error, or anything, just no document."

What I could not (yet?) reproduce is a repair dialog appearing.

So, the new NEEDINFO request is whether there is anybody

(In reply to comment #20)
> So, the new NEEDINFO request is whether there is anybody

please ignore that junk at the end of the comment

(In reply to comment #20)
> What I could not (yet?) reproduce is a repair dialog appearing.
As it's reproducible only under Ubuntu 12.04, I guess it's caused by old versions of GNOME\Samba libs. This explains the fact you can't reproduce that on a recent distro.

(In reply to comment #22)
> (In reply to comment #20)
> > What I could not (yet?) reproduce is a repair dialog appearing.
> As it's reproducible only under Ubuntu 12.04, I guess it's caused by old
> versions of GNOME\Samba libs. This explains the fact you can't reproduce
> that on a recent distro.

That makes it sound suspiciously like yet another fallout of GLib bug <https://bugzilla.gnome.org/show_bug.cgi?id=695925> "GUINT32/64_SWAP_LE_BE macros do not enclose val argument in parentheses," "which [...] caused trouble with LibreOffice, where running 'soffice sftp://.../.../test.odt' to access an .odt file via GVFS failed to properly type-detect that file as a Writer document and produced bogus error messages about the file being broken."

(In reply to comment #23)
> (In reply to comment #22)
> > (In reply to comment #20)
> > > What I could not (yet?) reproduce is a repair dialog appearing.
> > As it's reproducible only under Ubuntu 12.04, I guess it's caused by old
> > versions of GNOME\Samba libs. This explains the fact you can't reproduce
> > that on a recent distro.
> 
> That makes it sound suspiciously like yet another fallout of GLib bug
> <https://bugzilla.gnome.org/show_bug.cgi?id=695925> "GUINT32/64_SWAP_LE_BE
> macros do not enclose val argument in parentheses," "which [...] caused
> trouble with LibreOffice, where running 'soffice sftp://.../.../test.odt' to
> access an .odt file via GVFS failed to properly type-detect that file as a
> Writer document and produced bogus error messages about the file being
> broken."

Björn, can you verify whether on Ubuntu 12.04 this issue is indeed caused by <https://bugzilla.gnome.org/show_bug.cgi?id=695925> "GUINT32/64_SWAP_LE_BE macros do not enclose val argument in parentheses" not yet being fixed?  (Note that it does not suffice to have that GLib header fix in place, you also need to have any relevant packages that include that header rebuilt.)

Confirming Ubuntu 12.04 does not have the extra parathesis, filed:

 https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1214352

and adding remote bugs.

@Stephan Bergmann: Just tried to install gnome-vfs2-smb on Fedora 19 as you suggested, but in my case it didn't help. LO 4.1.0.4 from libreoffice.org still closes immediately, either when double-clicking in nautilus or using the CLI. BUT it helps with 4.2.0.0.alpha0+ Build ID: f4004429d339009bec6babe30becdc9c727940b8 TinderBox: Linux-x86-64@8-SLED11, Branch:master, Time: 2013-08-18_23:20:11

There is a problem also with distro's (Fedora 19) packages you didn't notice: The CLI doesn't work until you open nautilus and manually open the share. It's a problem because the whole point of using CLI is to avoid the GUI.

It's even worse for KDE users, since they can't even open by double-clicking in Dolphin, until they open nautilus and manually mount the share (although this can be avoided, by appling the workaround from comment 15, or by reverting commit 673be8e76856c6bc39f448f3374db4ae84258952)

BTW There is a seperate bug report about the CLI (bug 49776). Should we close it as a duplicate of the current bug?

[Please note bug 49776 comment 6 about the two different kinds of LO builds involved, the --enable-gnome-vfs and --enable-gio kinds.]

(In reply to comment #26)
> @Stephan Bergmann: Just tried to install gnome-vfs2-smb on Fedora 19 as you
> suggested, but in my case it didn't help. LO 4.1.0.4 from libreoffice.org
> still closes immediately, either when double-clicking in nautilus or using
> the CLI.

Hm, that's bad, and I cannot reproduce it on my up-to-date Fedora 19 x86_64 box with <http://donate.libreoffice.org/home/dl/rpm-x86_64/4.1.0/en-US/LibreOffice_4.1.0_Linux_x86-64_rpm.tar.gz>:  With the setup from comment 20, "/opt/libreoffice4.1/program/soffice smb://127.0.0.1/"$USER"/Documents/test.odt" first pops up an "Authentication Required" dialog and then loads the document.

> BUT it helps with 4.2.0.0.alpha0+ Build ID:
> f4004429d339009bec6babe30becdc9c727940b8 TinderBox: Linux-x86-64@8-SLED11,
> Branch:master, Time: 2013-08-18_23:20:11

OK, that tinderbox is indeed one that produces LO builds of the first, --enable-gnome-vfs kind (cf. e.g. <http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&full-log=1377058201.26472#5>), so it will be affected by presence of gnome-vfs2-smb package.  Odd though that things don't work for you with the above LO 4.1 of the same kind.

> There is a problem also with distro's (Fedora 19) packages you didn't
> notice: The CLI doesn't work until you open nautilus and manually open the
> share. It's a problem because the whole point of using CLI is to avoid the
> GUI.

See the comment at <https://bugzilla.redhat.com/show_bug.cgi?id=895690#c15> "Libreoffice causing errors when SAVING files by gvfs-mount (Samba)."

> BTW There is a seperate bug report about the CLI (bug 49776). Should we
> close it as a duplicate of the current bug?

I would prefer to wait until somebody who observed that bug in the past with a LO build of one kind is able to verify the bug is fixed with a later LO build of the same kind.

Same problem as comment 19 with Ubuntu 13.04. simply no document. 4.0.2.2 works fine, 4.1 does not.

(In reply to comment #28)
> Same problem as comment 19 with Ubuntu 13.04. simply no document. 4.0.2.2
> works fine, 4.1 does not.
Hi,
Unfortunately you didn't say which LO package do you use - from PPA or from libreoffice.org. Each of them has completely different problems.

- If you're using the packages from PPA, then the bug should be solved with 4.1.2 (unfortunately the PPA currently stuck with 4.1.1). When it will be updated to 4.1.2, it should work if you also install 'gvfs-backends' and 'libreoffice-gnome' packages. That way it works with Ubuntu 13.10.

- If you're using the packages from libreoffice.org site, then theoretically it should work if you install 'libgnomevfs2-extra' package. But for some reason it's not working. I can confirm that it's not working with 4.1.2.3 under both Ubuntu 13.04 and 13.10 (64-bit). Same happens under Fedora 19 (64-bit), as you can see from the first paragraph of comment 26. And it's still the case for 4.1.2.3. There is definitely some problem with the official builds.

So currently you have to apply the workaround from comment 15, or upgrade to Ubuntu 13.10.

Problem still exists, it seems, for me.  Using Fedora 19 x64 this time, and the RPMs from the LibreOffice site.  Version 4.1.3.

Can someone do a bibisect of this so that we can maybe get a range? 

https://wiki.documentfoundation.org/QA/HowToBibisect

(In reply to comment #31)
> Can someone do a bibisect of this so that we can maybe get a range? 
@Joel Madero: There is no need for bibisect. The problem probably is with the build environment where we build official releases (maybe some old headers or something similar). Please see Stephan Bergmann's comment at comment 20 that it works in his own build, and also see my comment at comment 26 that it works with a build from tinderbox, but not with the official build. Same under Ubuntu - see comment 29.

(In reply to comment #29)
> - If you're using the packages from PPA, then the bug should be solved with
> 4.1.2 (unfortunately the PPA currently stuck with 4.1.1). When it will be
> updated to 4.1.2, it should work if you also install 'gvfs-backends' and
> 'libreoffice-gnome' packages. That way it works with Ubuntu 13.10.
Note that the ppa has:
1:4.1.3~rc2-0ubuntu1~saucy1~ppa3
1:4.1.3~rc2-0ubuntu1~raring1~ppa1
1:4.1.3~rc2-0ubuntu1~precise1~ppa1

so all versions should be good, unless the bug is in the respective baseline on that ppa.

(In reply to comment #30)
> Problem still exists, it seems, for me.  Using Fedora 19 x64 this time, and
> the RPMs from the LibreOffice site.  Version 4.1.3.

What problem exactly still exists?

Also, do you have the gnome-vfs2-smb package installed, see comment 20?

(In reply to comment #34)
> What problem exactly still exists?
@Stephan Bergmann: Bryan Berndt explained his problem at comment 19.

(In reply to comment #35)
> (In reply to comment #34)
> > What problem exactly still exists?
> @Stephan Bergmann: Bryan Berndt explained his problem at comment 19.

Ah, right.  So /if/ he doesn't have gnome-vfs2-smb package installed, his findings in comment 30 would be consistent with my findings in comment 20.

Bryan, can you please clarify?

@Stephan Bergmann: I found what causes the problem with the official build: Looking at the strace output showed that libORBit-2.so.0 can't be found. So I did 'sudo yum install ORBit2' and now it works!

(In reply to comment #33)
> Note that the ppa has:
> 1:4.1.3~rc2-0ubuntu1~saucy1~ppa3
> 1:4.1.3~rc2-0ubuntu1~raring1~ppa1
> 1:4.1.3~rc2-0ubuntu1~precise1~ppa1
> 
> so all versions should be good, unless the bug is in the respective baseline
> on that ppa.
Indeed. I can confirm that it works now under Ubuntu 13.04 (64-bit). Thanks.

(In reply to comment #37)
> @Stephan Bergmann: I found what causes the problem with the official build:
> Looking at the strace output showed that libORBit-2.so.0 can't be found. So
> I did 'sudo yum install ORBit2' and now it works!
I can confirm the same for Ubuntu 13.10 (64-bit). Installing 'liborbit2' package solves the problem.

But unfortunately it still won't work under KDE, unless exporting 'OOO_FORCE_DESKTOP=gnome'. That is: Running 'soffice smb://some_ip/share/document.odt' under KDE doesn't work, but 'OOO_FORCE_DESKTOP=gnome soffice smb://some_ip/share/document.odt' does work. Tested under Fedora 19 (64-bit) & Ubuntu 13.10 (64-bit). Tested with 4.1.3.2 & master build (Build ID: 732ec36edfd09d2091d70c4d71b5f182fe279c45 TinderBox: Linux-rpm_deb-x86_64@46-TDF) built with --enable-gnome-vfs.

Same for MATE desktop. Tested with MATE 1.6.0 under Fedora 19 (64-bit) & LMDE MATE Edition (64-bit).

*** Bug 71981 has been marked as a duplicate of this bug. ***

@Stephan Bergmann: I found why builds with --enable-gnome-vfs won't work under KDE. It's because there is a check for GNOME desktop at http://opengrok.libreoffice.org/xref/core/desktop/source/app/appinit.cxx#86. Removing that check solves the problem. Is it OK to just remove that check, or there could be some side effects which I'm not aware of?

(In reply to comment #41)
> @Stephan Bergmann: I found why builds with --enable-gnome-vfs won't work
> under KDE. It's because there is a check for GNOME desktop at
> http://opengrok.libreoffice.org/xref/core/desktop/source/app/appinit.cxx#86.
> Removing that check solves the problem. Is it OK to just remove that check,
> or there could be some side effects which I'm not aware of?

No idea whether it would make sense to use that GnomeVFSContentProvider on non-Gnome desktops, too.  Maybe mmeeks knows?

In general not using gnome-vfs at all is what makes most sense ;-)
gio - if anything - but surely KIO uses paths into a FUSE mount just like GNOME does - making that mostly pointless ?

(In reply to comment #43)
> but surely KIO uses paths into a FUSE mount just like GNOME does -
> making that mostly pointless ?
No, KIO doesn't deal with any kind of mount. It just downloads the file into a temp folder, and opens it from there. It may cause troubles as in Bug 39591.

The problem now is that starting with 4.1 the .desktop files contain 'X-KDE-Protocols' definition, which is the equivalent of 'X-GIO-NoFuse'. So when users double-click on a file we get 'smb://adderss/share/filename', and should deal with it ourselves. And because the official build uses gnome-vfs, it fails. So there are 3 solutions:

1. Make gnome-vfs work under KDE as suggested above.
2. Force gnome desktop in official build (by exporting OOO_FORCE_DESKTOP=gnome in startup script, or something similar). It won't hurt anyone, since we don't ship KDE4 integration anyway.
3. Remove 'X-KDE-Protocols' from .desktop files. (But it will bring back Bug 39591.)

(In reply to comment #44)
> 3. Remove 'X-KDE-Protocols' from .desktop files. (But it will bring back Bug
> 39591.)
Also it won't solve the problem for MATE desktop, which is not detected as GNOME (See http://opengrok.libreoffice.org/xref/core/vcl/unx/generic/desktopdetect/desktopdetector.cxx#369. BTW the code there is broken, since MATE doesn't define XDG_CURRENT_DESKTOP)

Still an issue with Ubuntu 12.04.3 and LibreOffice 1:4.1.3~rc2-0ubuntu1~precise1~ppa1

confirming the problem still exists in Ubuntu 12.04.3, with LO 4.1.3 PPA version (version 4.1.3~rc2-0ubuntu1~precise1~ppa1) as prior comment indicates.  Workaround of:

sudo sed -i 's/X-GIO-NoFuse=true/#X-GIO-NoFuse=true/' /usr/share/applications/libreoffice-* as

as alluded to above does seem to help.

Update: attempting to open a .odt on a remote linux share using sftp (so not using samba) will result in the SAME ERROR.  The .desktop sed hack does NOT solve the problem in this regard.  So, from what I know there is no workaround for Ubuntu 12.04.3 to open .odf files on sftp shares.

*** Bug 73187 has been marked as a duplicate of this bug. ***

(In reply to comment #48)
> Update: attempting to open a .odt on a remote linux share using sftp (so not
> using samba) will result in the SAME ERROR.  The .desktop sed hack does NOT
> solve the problem in this regard.  So, from what I know there is no
> workaround for Ubuntu 12.04.3 to open .odf files on sftp shares.

Hi. This works fine with precise.  Is there an lp for this ?

(In reply to comment #36)
> (In reply to comment #35)
> > (In reply to comment #34)
> > > What problem exactly still exists?
> > @Stephan Bergmann: Bryan Berndt explained his problem at comment 19.
> 
> Ah, right.  So /if/ he doesn't have gnome-vfs2-smb package installed, his
> findings in comment 30 would be consistent with my findings in comment 20.
> 
> Bryan, can you please clarify?

Sorry, been away for a while. And Just added myself to the CC list, so I can try to keep up.

Im now on Fedora 20, x64, and using Libre Office 4.1.4.  problem still exists, as explained in comment 19. Though, the failure is MUCH faster, less than a second.

The fix in comment 15 still works, as well. 

I use KDE, gnome-vfs2-smb is NOT installed.

Hi

(In reply to comment #51)
> (In reply to comment #36)
> > (In reply to comment #35)
> > > (In reply to comment #34)
> > > > What problem exactly still exists?
> > > @Stephan Bergmann: Bryan Berndt explained his problem at comment 19.
> > 
> > Ah, right.  So /if/ he doesn't have gnome-vfs2-smb package installed, his
> > findings in comment 30 would be consistent with my findings in comment 20.
> > 
> > Bryan, can you please clarify?
> 
> Sorry, been away for a while. And Just added myself to the CC list, so I can
> try to keep up.
> 
> Im now on Fedora 20, x64, and using Libre Office 4.1.4.  problem still
> exists, as explained in comment 19. Though, the failure is MUCH faster, less
> than a second.
> 
> The fix in comment 15 still works, as well. 
> 
> I use KDE, gnome-vfs2-smb is NOT installed.

works fine using lo 4.1.4 shipped with fc20. Would you provide the "ps aux" o/p , after trying to open the document ( without the c#15 workaround).

I personally prefer this (c#15). Is there a reason we do not do delegate this to gvfs/kio backend by default ?


__self:
http://techbase.kde.org/Projects/KioFuse
https://wiki.gnome.org/Projects/KioGioBridge

Created attachment 93088 [details]
'ps aux' immediately after failed attempt to open an xls file from SMB share

'ps aux' immediately after failed attempt to open an xls file from SMB share 

As requested.

I removed the comment in the .desktop file or Libreoffice Calc. (comment 15) Then tried to open an xls file from a SMB share, by doubleclicking on the icon in Dolphin. I see the Libreoffice logo for a second, and then nothing.

I have just confirmed this bug is NOT PRESENT for the following:

Client: Ubuntu 14.04
LibreOffice Version 4.1.3.2
Connection: smb:// from nautilus, so mounted to ~/.gvfs

Client: Ubuntu 12.04.3
LibreOffice Version: 4.1.4.2
Connection: cifs entry in /etc/fstab

I have just confirmed this bug IS STILL present for the following:

Client: Ubuntu 12.04.3
LibreOffice Version: 4.1.4.2
Connection: smb:// from nautilus, so mounted to ~/.gvfs

(the work-around from comment 15 above does still work, however)

Sorry I wasn't clear enough: I mean that in Ubuntu 14.04 this bug seems SOLVED.  The workaround of comment 15 is NOT REQUIRED.

Just tried the latest LibreOffice 4.2.0.4 from the main libreoffice site.

Problem still exists (comment 19), and is still fixed with comment 15.

Bryan,

What OS are you running?  Again from my testing I see the problem SOLVED in Ubuntu 14.04, but still present in Ubuntu 12.04.  It is some combination of LibreOffice 4.1 (+) in combination with *something* present in Ubuntu 12.04 that is not in Ubuntu 14.04.  I am not sure about interim releases.  I can't speak to Windows or OSX.

Bryan, sorry I missed the earlier comment where you indicate you are using Fedora 20, KDE desktop.

To clarify, my testing results above are with Gnome-Shell / Unity / Cinnamon desktops, and I have not tested with KDE.

@iveand, Bryan Berndt: Too bad you didn't read carefully the whole thread. Anyway, here is a summary:

- The repair dialog is an Ubuntu 12.04 specific bug, related to glib package. See https://launchpad.net/bugs/1214352

The problem with KDE is another problem, mostly related to missing packages:

- For the build from distro repositories, you should also install 'gvfs' and 'gvfs-smb' packages for Fedora, or 'gvfs', 'gvfs-backends', 'libreoffice-gnome' for Ubuntu.

- For the build from libreoffice.org, you should also install 'gnome-vfs2', 'gnome-vfs2-smb', 'ORBit2' for Fedora, or 'libgnomevfs2-0', 'libgnomevfs2-extra', 'liborbit2'. You should also export 'OOO_FORCE_DESKTOP=gnome', otherwise it won't work.

I have the same problem with version 4.1.5.3
mainly libreoffice files .odt .ods .odp

My SO: Ubuntu 12.04

Same problem.
Kubuntu 13.10
Libreoffice 4.1.5 (PPA)

Same problem on Ubuntu 12.04/64 with LibreOffice 4.2.1.1 (ppa)

Same problem on Ubuntu 12.04/64 with LibreOffice 4.2.1.1 (download from LO site)

*** Bug 75055 has been marked as a duplicate of this bug. ***

*** Bug 58236 has been marked as a duplicate of this bug. ***

(In reply to comment #59)
> @iveand, Bryan Berndt: Too bad you didn't read carefully the whole thread.
> Anyway, here is a summary:
> 
> - The repair dialog is an Ubuntu 12.04 specific bug, related to glib
> package. See https://launchpad.net/bugs/1214352
> 
> The problem with KDE is another problem, mostly related to missing packages:
> 
> - For the build from distro repositories, you should also install 'gvfs' and
> 'gvfs-smb' packages for Fedora, or 'gvfs', 'gvfs-backends',
> 'libreoffice-gnome' for Ubuntu.
> 
> - For the build from libreoffice.org, you should also install 'gnome-vfs2',
> 'gnome-vfs2-smb', 'ORBit2' for Fedora, or 'libgnomevfs2-0',
> 'libgnomevfs2-extra', 'liborbit2'. You should also export
> 'OOO_FORCE_DESKTOP=gnome', otherwise it won't work.

Upgraded to LO 4.3 with the rpm's from the LO web site. (rpm -U.....) Problem is recreated, as with every upgrade so far (comment 15).  Most of the packages you mention were already installed.  Then added  the export to a KDE environment script: http://forums.opensuse.org/showthread.php/478619-LibreOffice-looks-ugly-in-SUSE-KDE ; vairation of post #3.

I log into the SMB file server, and then when I double click the file I want to opem it asks to log in again, I assume that this is GVFS asking that.  Once I do, then file opens.

Again: This one doesn't need bibisecting.

Scoping this bug clearly only on the missing deps for KDE thanks to the excellent summary in comment 59. Everything else is fdo#49776. Please dont scope-creep this bug, thanks.

(In reply to Björn Michaelsen from comment #68)
> Scoping this bug clearly only on the missing deps for KDE thanks to the
> excellent summary in comment 59.

...which has become moot with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=f9f9aa9873c5851da86d33ca75e937ac022206a3> "Remove smb from X-KDE-Protocols lines," see <http://lists.freedesktop.org/archives/libreoffice/2014-October/063904.html> "Re: X-KDE-Protocols=...,smb,..."