My Fedora 41 Qubes throw an error opening files received via "Edit in disposable qube"

User Support General
1

Ever since I’ve upgraded my templates to fedora-41 my workflow has been crippled by this issue. Honestly each fedora upgrade costs me so much time and energy I ended up spending Christmas exploring marginally less secure alternatives to QubesOS. As it is if I can resolve this I’ll probably settle for making as much of my setup Debian as possible so only 40% of my computer gets broken twice a year. Sorry, I’m ranting, here’s the actual issue.

Whenever I use “Edit in disposable qube” to send a file to a fedora-41 disposible it shows a popup with the following error:

Unable to handle mimetype of the requested file (exit status:256)

It also completely ignores “/home/user/.local/share/applications/mimeapps.list” and proceeds to attempt to open the file in whatever the OS default is or, (in the case of any remotely interesting file-type,) fails to open the file all-together.

The truly bizarre part is if I then send the exact same file to the exact same disposable Qube via “copy to other qube” and then double click it in Thunar, my mimeapps.list is obeyed and my files open in my chosen applications without error.

The error happens for any filetype i’ve specified in the mimeapps.list, and the same mimeapps.list worked fine with previous versions of fedora.

I’ve tried basing my disposable template on both fedora-41-minimal and fedora-41-xcfe. I’ve also made sure perl-File-MimeInfo is installed, which was inexplicably required for certain MimeTypes like text/markdown to be obeyed in fedora-40.

As usual, I’d be grateful for any help. I can’t be the only person highly reliant on mimeapps.list, even hearing from somebody else who uses a fedora-41 disposable with a custom mimeapp.list and doesn’t have issues could be helpful.

2 Likes
2

A little detail would be helpful.
What is the file type?
What program do you expect to use?

Your rant suggests that this worked in fedora-40 with the custom
mimeapps entry in the disposable template, but does not work in the same
disposable template when using the fedora-41 template. Is this correct?

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

2 Likes
3

Hi unman, thanks for the response.

Sorry I took so long to reply, I thought I better spin up some Qubes and triple check things before I got back to you.

I can now confirm that this issue definitely occurs with fedora-41-xfce and not fedora-40-xfce.

I’ve tested with both templates, having only made the same singular change to each of them. That change was installing xed via:

sudo dnf install xed

I’ve then applied both templates to the same new disposable Qube with the following /home/user/.local/share/applications/mimeapps.list:

[Default Applications]
application/octet-stream=xed.desktop;
text/plain=xed.desktop;
application/x-sh=xed.desktop;
application/x-shellscript=xed.desktop;
text/x-shellscript=xed.desktop;
text/markdown=org.kde.ghostwriter.desktop;
application/pdf=qpdfview-qt5.desktop;
application/vnd.oasis.opendocument.text=libreoffice-writer.desktop;
image/x-compressed-xcf=krita_xcf.desktop;
image/x-xcf=krita_xcf.desktop;
image/x-psd=krita_psd.desktop;
image/x-fits=org.kde.krita.desktop;
image/bmp=org.kde.krita.desktop;
image/gif=krita_gif.desktop;
image/x-icb=org.kde.krita.desktop;
image/x-ico=org.kde.krita.desktop;
image/x-pcx=org.kde.krita.desktop;
image/x-portable-anymap=org.kde.krita.desktop;
image/x-portable-bitmap=org.kde.krita.desktop;
image/x-portable-graymap=org.kde.krita.desktop;
image/x-portable-pixmap=org.kde.krita.desktop;
image/x-xbitmap=org.kde.krita.desktop;
image/x-xpixmap=org.kde.krita.desktop;
image/svg+xml=krita_svg.desktop;
image/bmp=org.kde.krita.desktop;
image/gif=krita_gif.desktop;
image/jpeg=krita_jpeg.desktop;
image/jpg=krita_jpeg.desktop;
image/pjpeg=krita_jpeg.desktop;
image/png=krita_png.desktop;
image/tiff=krita_tiff.desktop;
image/x-bmp=org.kde.krita.desktop;
image/x-gray=org.kde.krita.desktop;
image/x-icb=org.kde.krita.desktop;
image/x-ico=org.kde.krita.desktop;
image/x-png=krita_png.desktop;
image/x-portable-anymap=org.kde.krita.desktop;
image/x-portable-bitmap=org.kde.krita.desktop;
image/x-portable-graymap=org.kde.krita.desktop;
image/x-portable-pixmap=org.kde.krita.desktop;
image/x-xbitmap=org.kde.krita.desktop;
image/x-xpixmap=org.kde.krita.desktop;
image/x-pcx=org.kde.krita.desktop;
image/svg+xml=krita_svg.desktop;
image/svg+xml-compressed=krita_svg.desktop;
image/vnd.wap.wbmp=org.kde.krita.desktop;

When the fedora-40-xfce template is in use, a .txt file sent to the qube via “Edit in disposable qube” opens in xed as expected. However when the fedora-41-xfce template is in use the same .txt file sent via "Edit in disposable qube” ignores the mimeapps.list and opens in geany instead.

Testing .txt (text/plain) files is the easiest way to check this. But I encounter the same problem with .md (text/markdown) and .sh (text/x-shellscript) files.

1 Like
4

It would, I think, be helpful if the new template actually had a
xed.desktop file.

Copy the file from your fedora-40-xfce to your new template.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

1 Like
5

Good find! Thanks unman!

That solved the issue for templates based on fedora-41-xfce, sadly I still get the original error on my templates built up from fedora-41-minimal with custom setup scripts (though it at least opens now), but that’ll just be some new dependency I need to find much like how I had to find perl-File-MimeInfo in the past. Now I know it works in a proper template the problem is much less daunting.

That said, that xed desktop file being missing means that redhat managed to launch fedora 41 with three of my frequently used apps broken (unless users fix them their end): ghostwriter, zulucrypt and xed. And that’s even for non-QubesOS users. So I think there’s no point in me wasting any more time trying to maintain custom scripts for fedora templates, life’s too short to keep fixing fedora.

I’m going to move (almost) everything over to Debian and use the official fedora flatpak remote for the few apps I absolutely need to be up to date, I think that’s the best solution, and will save me a lot of time in the long term.

1 Like