Libreoffice 6.0.3 not so stable

jorge@jorge-Lenovo-ideapad-110-15ISK:~$ snap info core libreoffice | egrep “name|tracking|refreshed|installed”
name: core
tracking: stable
refreshed: 2018-04-05T18:16:52-03:00
installed: 16-2.32.3 (4407) 90MB core
name: libreoffice
tracking: stable
refreshed: 2018-04-04T12:51:36-03:00
installed: 6.0.3.2 (59) 479MB -
jorge@jorge-Lenovo-ideapad-110-15ISK:~$ echo $HOME
/home/jorge
jorge@jorge-Lenovo-ideapad-110-15ISK:~$ snap interfaces libreoffice
Slot Plug
:cups-control firefox,libreoffice
:desktop eog,evince,firefox,gedit,gimp,gnome-calculator,gnome-chess,gnome-clocks,gnome-mines,gnome-system-monitor,libreoffice,spotify,telegram-desktop,vlc
:gsettings eog,evince,firefox,gedit,gimp,gnome-calculator,gnome-chess,gnome-clocks,gnome-mines,gnome-system-monitor,libreoffice,spotify,telegram-desktop
:home eog,evince,firefox,gedit,gimp,libreoffice,spotify,telegram-desktop,vlc
:network eog,evince,firefox,gedit,gnome-calculator,gnome-chess,libreoffice,spotify,telegram-desktop,vlc
:network-bind libreoffice,telegram-desktop,vlc
:opengl firefox,gimp,libreoffice,spotify,vlc
:pulseaudio firefox,gnome-chess,gnome-clocks,gnome-mines,libreoffice,spotify,telegram-desktop,vlc
:removable-media libreoffice,vlc
:unity7 eog,evince,firefox,gedit,gimp,gnome-calculator,gnome-chess,gnome-clocks,gnome-mines,gnome-system-monitor,libreoffice,spotify,telegram-desktop,vlc
:wayland eog,evince,gedit,gimp,gnome-calculator,gnome-chess,gnome-clocks,gnome-mines,gnome-system-monitor,libreoffice,spotify

  •             libreoffice:bluez
    

jorge@jorge-Lenovo-ideapad-110-15ISK:~$

I had the exact same problem and the weird thing was that nothing was apparent. I would edit a spreadsheet, exit, confirm save (in a folder below ~), no warnings or problems. File access time never changed and none of the changes was recorded. I remember an old blogpost that said to install in classic mode so did and everything is fine. I was switching over to all snaps when available and just assumed I still needed to install in this mode and had forgotten.

libreoffice is a strictly confined snap, it’s not meant to install in classic mode (I don’t think passing --classic to the snap install command would do anything, actually).

Everything looks alright there. What’s your distribution (output of lsb_release -a) and what’s the filesystem type of the partition where your home sits (output of mount | grep home)?

Are you seeing apparmor denials related to libreoffice when saving a document fails? You can monitor those by running the following command in a terminal while running libreoffice:

journalctl -f | grep libreoffice

That’s what I was expecting. I hadn’t tried it in a while and just assumed I was wrong so re-installed with the flag so I guess I can’t really say what the actual problem was because now it works. I have some fresh installs coming up so I’ll keep track.
I couldn’t use it that way so had to solve the problem within hours so don’t have much good info, but is it possible that the fact I was starting LO by double clicking on existing .ods files affect anything? Or that I had switched to the snap version after completely uninstalling an up to date PPA apt install? Just tossing things out in case anything clicks.

No, that shouldn’t affect the way libreoffice is being run (and confined). And the coexistence of the two packages (deb and snap) shouldn’t be a problem either.

I wonder if this is simply another instance of: Bug? Saves are blocked to $SNAP_USER_DATA if snap updates when it is already running

That’s failing to save a document to $HOME, not $SNAP_USER_DATA.

@jor1196, you’re not trying to save to a path below a hidden directory (one that starts with a dot), are you? Because the home interface doesn’t allow that. So saving to $HOME/.documents is intentionally disallowed, whereas saving to $HOME/documents is permitted.

Are you still seeing the issue across reboots?

I was not saving anything in hidden directories

https://www.dropbox.com/s/ivpv4e7tnd5jlil/journal.txt?dl=0

The following denial looks suspicious (and possibly related):

abr 20 03:50:40 jorge-Lenovo-ideapad-110-15ISK audit[24842]: AVC apparmor=“DENIED” operation=“mknod” profile=“snap.libreoffice.writer” name=2F686F6D652F6A6F7267652F2E7E6C6F636B2E53696E2074C3AD74756C6F20312E6F647423 pid=24842 comm=“soffice.bin” requested_mask=“c” denied_mask=“c” fsuid=1000 ouid=1000

Use aa-decode for this:

$ echo abr 20 03:50:40 jorge-Lenovo-ideapad-110-15ISK audit[24842]: AVC apparmor=“DENIED” operation=“mknod” profile=“snap.libreoffice.writer” name=2F686F6D652F6A6F7267652F2E7E6C6F636B2E53696E2074C3AD74756C6F20312E6F647423 pid=24842 comm=“soffice.bin” requested_mask=“c” denied_mask=“c” fsuid=1000 ouid=1000 | aa-decode
abr 20 03:50:40 jorge-Lenovo-ideapad-110-15ISK audit[24842]: AVC apparmor=“DENIED” operation=“mknod” profile=“snap.libreoffice.writer” name="/home/jorge/.~lock.Sin título 1.odt#" pid=24842 comm=“soffice.bin” requested_mask=“c” denied_mask=“c” fsuid=1000 ouid=1000

Ie name="/home/jorge/.~lock.Sin título 1.odt#". This is trying to create a hidden lockfile in the ~, which is not allowed.

That makes sense. Libreoffice wants to create a lock file next to the saved file, and the home interface doesn’t allow that in $HOME (but it does in subdirectories).

@jor1196: saving the file anywhere in a subdirectory of $HOME should work, can you please test and confirm?

Brand new minimal install of 18.04 Beta 2. Snap install LO. Can not create a lock file in the $HOME but everything works fine in ~/Documents.

1 Like

there are no problems in the subdirectories

Why is this not permitted and could it be permitted to allow LibreOffice to be more feature-parible with the Deb OOTB?

(cc @niemeyer)

Alternatively, could the LO snap be patched to give an appropriate (GUI) error when a user tries to save to the home directory? I.e. directly stating that they can’t save to home on their LO install?

Whether by punching a hole in the apparmor profile or by patching libreoffice, this should be fixed so that users are allowed to save documents under $HOME. A better error message would be only slightly less bad, because really there’s no good reason for not allowing to save documents under $HOME.

I have filed bug #1766192 to track the issue.

1 Like

and it’s been a year

Unless you have a solution which you can get a consensus from snappy developers for and commit to the repository, it could be many years before this issue is resolved, we have no choice but to wait and get people affected by the bug to mark themselves as affected by it.

How many years do you have to wait for a solution?