LibreOffice Problem

I’ve been having a problem opening any LibreOffice application ever since my last update of Leap 42.2. This was approx 3-4 weeks before Leap 42.3 came out. Which I thought might fix things. But it didn’t. It’s the same.

It doesn’t matter if I click on LibreOffice icon, or any of the individual icons. I get LibreOffice trying to load, but it get’s stuck, and doesn’t load. I don’t know what else to say. It’s the same on my desktop and laptop. I even tried to delete LibreOffice and reinstall. Same problem.

Does anybody recognize these symptoms and have any clues how I might fix this?

I don’t have a solution, sorry, but my suggestion would be to get more info so that experts here [ie, [u]not me] might be able to solve it. So, rather than trying to launch LO via menu, try launching it from Konsole / Terminal, then copy the subsequent [presumed] error messages that result, & paste here in a codebox.

Please start LibreOffice from a GUI Terminal Window – you don’t mention which Desktop you’re using – and, post the Terminal output here.
Also, please post the output of ‘which’.

For example: Leap 42.2, KDE Plasma 5 with the Oxygen Theme – therefore the “doesn’t matter, it still works” error message . . . :wink:

 > which -a libreoffice
 > l /usr/bin/libreoffice
lrwxrwxrwx 1 root root 36 13. Jul 21:49 /usr/bin/libreoffice -> ../lib64/libreoffice/program/soffice*
 > libreoffice

(soffice:7245): Gtk-WARNING **: Theme directory base/ of theme oxygen has no size field


OK. I noticed 1 thing. If I open File Manager Super User and navigate to Root>usr>bin and click libreoffice. It works fine. What does that tell me?

My Office.Desktop file in 42.3 is

#!/usr/bin/env xdg-open[Desktop Entry]

Does that look right to anybody? It looks somewhat different to 42.2. For example StartUpNotify=true in 42.2

I’m using KDE

Output of which

# which -a libreoffice/usr/bin/libreoffice

# l /usr/bin/libreoffice
lrwxrwxrwx 1 root root 36 Jul 27 16:35 /usr/bin/libreoffice -> ../lib64/libreoffice/program/soffice*

# libreoffice

If you can launch libreoffice from superuser and cannot from yourself, looks like the problem is in either your configs, or in some subtle superuser-related rights.
I’d suggest to create a new test user (via YaST), re-login under this new user, and try to launch libreoffice (preferably from konsole). It this succeeds, re-login under yourself again, remove configs (/home/<your_username>/.config/libreoffice, and /home/<your_username>/.libreoffice, if exists), and try to launch libreoffice again.
If this does not succeed, the problem is more difficult, and we shall continue debugging.

What are the protections of “/usr/lib64/libreoffice/program/” and “/usr/lib64/libreoffice/program/soffice”?

Please also, verify your packages – with the user “root”:

 # zypper verify --details | less
 # rpm --verify --all | less
 # rcrpmconfigcheck | less

Have you attempted to increase the system security by partially applying things SELinux does?
Have you applied some of things mentioned in the openSUSE Security Guide? <>

Twice already you have been asked to run LO from a terminal and post the results. This is probably the best starting point to debug your issue (it is for me). Or did you already try it but it didn’t help?

Sorry. I’ve had a busy couple of days. I’ll try to post the results today.But won’t that be the same as using File Manager Super User and navigate to Root>usr>bin and click libreoffice.

What is the path to LO in a terminal?

Additional information. I seem to be able to open a spreadsheet with permissions user:xxx group:xxxxx (my only settings) in File Manager Super User, but not in Dolphin. Which seems strange.

OK. I executed libreoffice from a Super User Terminal. Without any problems. But loading LO from Konsole hangs. The same results as when using File Manager Super User and Dolphin.

So. I think this is some kind of permissions problem, which got introduced with my last update of Leap 42.2 and has been carried forward since that time.

The question is. How can I fix that?

You seem to be having an issue with the UNIX® world and therefore also the Linux world . . .

  • The user “root” is NOT
    the same as a “normal” user.

The user “root” has system privileges and, shall not to be used for anything other than a few, well-defined, system administration tasks.

A “normal” user has a confined set of privileges which allow (via system calls) reading and writing the user’s own files plus, access, via system calls, to things such as the display, keyboard, mouse and network.

UNIX® and Linux (and Apple’s Mac OS, which is also a UNIX®) have the concept that, the machine as such (in other words the hardware) is controlled and accessed by the system only (which is where the user “root” comes in). A “normal” user has absolutely no direct access to any piece of the system’s hardware – all data passed between the system and the human user is achieved by means of system calls.

You have supplied the Konsole output for the user “root”.

Please supply the Konsole output for the case of a “normal” user – someone who is either a member of the group “users” or some other non-system group, who has a non-system UID and GID.

From a “normal” user’s CLI terminal prompt, " > which -a libreoffice" provides an absolutely complete and correct answer.

Strange, the system I’m using to type this reply is a Laptop which was upgraded from openSUSE Leap 42.2 to openSUSE Leap 42.3 by means of " # zypper dup".

And, LibreOffice is performing perfectly.

You have not mentioned how, you performed the upgrade from openSUSE Leap 42.2 to openSUSE Leap 42.3.

Did you follow the instructions in the openSUSE documentation?
Part III “Managing and Updating Software”
Chapter 12 “Upgrading the System and System Changes” – “Applies to openSUSE Leap 42.3”.

If you used " # zypper dup", did you take heed of the fact that, this method of upgrading a system is reliable if and only if the default system repositories are enabled?

stu@ZyXEL1:~> which -a libreoffice/usr/bin/libreoffice
which: no libreoffice in (./libreoffice/usr/bin)
stu@ZyXEL1:~> l /usr/bin/libreoffice
lrwxrwxrwx 1 root root 36 Jul 27 16:35 /usr/bin/libreoffice -> …/lib64/libreoffice/program/soffice*
stu@ZyXEL1:~> libreoffice

**I hope this is what you are requesting.

stu@ZyXEL1:~> which -a libreoffice

I did manage to figure that for myself :slight_smile: Breathing on fingers of clenched fist and then rubbing clenched fist on my shoulder :slight_smile:

The problem was already existing with my last upgrade of Leap 42.2. I’m assuming the settings from that bad upgrade, have been carried forward to today. I used Yast Online Update. I don’t recall having any problems with the the time. It seemed to run smoothly. Actually, these problems are with my Desktop. Not with my Laptop, as described earlier. I never did this last Leap 42.2 Yast Online Update on my Laptop, because I was afraid it might also render LibreOffice unusable also on the LapTop.

I installed Leap 42.3 from a Installation DVD. Whenever I install the latest version of Leap, I usually format the openSUSE Mount Point /. So it is a clean install of the Operating System. But I assume my settings from my previous install are saved somewhere and are copied over. So I’m assuming that I won’t be able to re-install Leap 42.2 because it will re-install the corrupt settings, just like it did when I installed Leap 42.3.

So i’m wondering if I can get my settings from my Laptop settings, which are not corrupted. However. Is it only LibreOffice which is corrupted? From my limited usage, I’d say yes. Simply because I’ve only encountered this from LO. Or maybe you can figure out the problem from my response to my permission settings above. I have a very simple setup. Just root root and stu users. So maybe if I could copy some settings from stu users from my laptop over to my desktop. That would probably do the trick. But I have no idea whether that is even possible. If not. I think I have to manually edit my stu users settings, based upon what you see is wrong with my settings, or from reading my settings from my laptop. Either way. I need some hand-holding to get it done.