Opening an RTF file from an ASiC-E container fails because the temporary file does not exist

[piiskop]

Description

Opening an RTF document directly from an ASiC-E container launches LibreOffice, but LibreOffice reports that the extracted temporary file does not exist.

Example error (temporary directory shortened to avoid personal data):

/tmp/qdigidoc4_…/Vastuskiri_14082026_110047.rtf does not exist.

The issue is reproducible after closing and reopening DigiDoc4 Client and the container. Saving the document from the container to a permanent folder first and opening the saved copy works.

Steps to reproduce

1. Open an ASiC-E container in DigiDoc4 Client.
2. Click an RTF file in the container to open it.
3. LibreOffice starts.
4. An error says that the file under /tmp/qdigidoc4_…/ does not exist.

Expected result

The RTF file is extracted to a temporary location and opens in LibreOffice.

Actual result

LibreOffice starts, but the temporary RTF file is already missing.

Environment

• DigiDoc4 Client: 4.11.0.5421
• LibreOffice: 26.2
• Operating system: Ubuntu Linux (exact version not yet recorded)

The container signature is shown as valid. No container or screenshot is attached because they contain personal data.

[kristelmerilain]

Thank you for reporting this issue and for the detailed description.

We were unable to reproduce the reported issue on an Ubuntu 26.04 machine using both the Snap and APT versions of LibreOffice. Opening an RTF file from an ASiC-E container worked as expected in both cases.

To help us investigate the issue further, could you please provide some additional information:

1. Does the issue occur only with RTF files, or also with other file types?
2. Is there definitely sufficient free space available in the /tmp directory for the temporary RTF file?
   On newer Ubuntu versions, /tmp may be mounted as a tmpfs filesystem, which is essentially a RAM-based filesystem. As a result, /tmp can run out of available space even when there is sufficient free space on the disk. Could you please check the available space using df -h and provide the output?

[piiskop]

I was able to reproduce the issue again, and I found an important detail that was missing from my original report.

The ASiC-E container is opened directly as an attachment from Thunderbird, not from the local filesystem.

Steps to reproduce:

Open an email containing an .asice attachment in Thunderbird.
Open the .asice attachment directly from Thunderbird without saving it first.
DigiDoc4 Client opens the container normally and displays the valid signature.
Click the RTF file inside the container.
LibreOffice starts, but reports:
/tmp/qdigidoc4_vmFaxp/Vastuskiri_14082026_110047.rtf does not exist.

Control test: if I first save the exact same .asice attachment to the local filesystem and then open it in DigiDoc4 Client, the RTF file opens normally.

So the problem appears specifically when the ASiC-E container itself has been opened directly from a Thunderbird attachment.

My environment:

Ubuntu 24.04.4 LTS
DigiDoc4 Client 4.11.0.5421
LibreOffice 26.2.5.2, Snap revision 377
LibreOffice APT package is not installed

/tmp is part of the root filesystem, not a separate tmpfs, and has about 110 GB free, so lack of temporary space does not appear to be the cause.

[piiskop]

I found another way to reproduce the same issue.

It is not specific to Thunderbird.

The same ASiC-E container also produces the error when opened from a NAS over SFTP through GNOME Files (GVFS). DigiDoc4 opens the container and shows the valid signature, but clicking the RTF starts LibreOffice and then results in:

/tmp/qdigidoc4_qmJKCx/Vastuskiri_14082026_110047.rtf does not exist.

So far I can reproduce it when the container is opened:

directly from a Thunderbird attachment;
from an SFTP/NAS location exposed through GNOME Files.

I have attached a screenshot of the SFTP/NAS case as well.

[piiskop]

Thanks. I reproduced the issue again.

I also tested the exact same ASiC-E container from three different sources:

opened directly as an attachment from Thunderbird;
opened from an SFTP/NAS location through GNOME Files;
copied to and opened from the local ~/Downloads directory.

The result is the same in all three cases. Clicking the RTF file starts LibreOffice, but LibreOffice reports that the temporary file created under /tmp/qdigidoc4_.../ does not exist.

Example:

/tmp/qdigidoc4_WCzuhx/Vastuskiri_14082026_110047.rtf does not exist.

So the issue does not appear to depend on whether the ASiC-E container itself is local, opened from Thunderbird, or opened via SFTP/GVFS.

Environment:

Ubuntu 24.04.4 LTS
DigiDoc4 Client 4.11.0.5421
LibreOffice 26.2.5.2, Snap revision 377
LibreOffice APT package is not installed

/tmp is not a separate tmpfs on this system. It is part of /dev/sda2, with about 110 GB free and plenty of free inodes.

I have attached screenshots showing the failure both from SFTP/NAS and from a local copy in ~/Downloads.

[piiskop]

I tested another ASiC-E container containing a PDF file. The PDF opens normally.

So far, I can reproduce the problem specifically with the RTF file. The RTF fails regardless of whether the container is opened from Thunderbird, from an SFTP/NAS location via GNOME Files, or from the local ~/Downloads directory.

In contrast, a PDF inside another ASiC-E container opens correctly from the same SFTP/NAS location.

The RTF failure is:

/tmp/qdigidoc4_.../Vastuskiri_14082026_110047.rtf does not exist.

My environment:

Ubuntu 24.04.4 LTS
DigiDoc4 Client 4.11.0.5421
LibreOffice 26.2.5.2, Snap revision 377
LibreOffice APT package is not installed

/tmp is part of /dev/sda2, with about 110 GB free and plenty of free inodes.

[metsma]

I think this is related to that LibreOffice is snap packaged application and it does not have access to this temp folder instead some mapped temp.

[piiskop]

I confirmed the cause.

My original LibreOffice installation was the Snap version:

LibreOffice 26.2.5.2
snap revision 377

With that version, opening the RTF from DigiDoc4 fails with:

/tmp/qdigidoc4_.../Vastuskiri_14082026_110047.rtf does not exist.

I installed the Ubuntu APT version of LibreOffice Writer alongside the Snap version:

LibreOffice 24.2.7.2 420(Build:2)

and made the APT Writer the default application for RTF files.

After that, the exact same RTF file from the exact same ASiC-E container opens successfully from DigiDoc4.

So this appears to be caused by the Snap confinement/private /tmp: DigiDoc4 creates the temporary file in the host /tmp, but the Snap-packaged LibreOffice cannot access that same temporary path.

The APT-packaged LibreOffice works correctly.

[piiskop]

The DEB build is a working workaround, but I do not think users should have to replace the Snap-packaged LibreOffice because of this.

On current Ubuntu Desktop, Snap is the preferred/default application distribution path in App Center. Therefore DigiDoc4 should ideally also work when the system's default handler is a confined Snap application.

The same document works with LibreOffice 26.2.6.3 installed from the official DEB packages, while LibreOffice 26.2.5.2 from Snap fails because it cannot access DigiDoc4's temporary file under the host /tmp.

So from a user perspective this appears to be a DigiDoc4 compatibility issue with sandboxed default applications rather than a LibreOffice version issue.

[metsma]

Yes we need to figure out some fix for this. Maybe use xdg-desktop-portal to open files instead Qt QDesktopServices::openUrl()

[metsma]

Seems like xdg-desktop-portal also does not work. Seems like some Snap missing feature (/tmp, $HOME/.cache, $HOME/.local/... etc).
One possible solution is to save to $HOME/qdigidoc4_xxxxx temp folder and then application on exit cleans folder/files.
I really do not see better solution right now

[piiskop]

That sounds like a reasonable solution.

It would also be useful to clean up stale ~/qdigidoc4_* directories on the next startup, in case DigiDoc4 crashes or is terminated before normal exit.