SUMMARY Dolphin is possibly not passing file URLs to the flatpaks of Okular and Gwenview. Opening PDF or image remote files via dolphin fails with error. STEPS TO REPRODUCE 1. Install Okular/Gwenview from Flathub or Fedora Flatpaks 2. Open Dolphin, connect to SMB or Webdav share 3. Double Click on a remote PDF or image 4. Get error box. OBSERVED RESULT Gwenview and Okular are unable to open the specified file associations when they are on a remote server provided by Dolphin. Timothée Ravier over on Fedora Discussion speculated that file URLs were not passed by Dolphin. https://discussion.fedoraproject.org/t/can-no-longer-open-files-with-okular-or-gwenview-on-a-dolphin-remote-share-smb-webdav-f39-kinoite/96788 Konsole output for SMB Connection. Cannot initialize model with data QJsonObject(). missing: QJsonValue(string, “urls”) QString::arg: 2 argument(s) missing in org.kde.okular kf.kio.widgets: Failed to check which JobView API is supported “org.freedesktop.DBus.Error.ServiceUnknown” kf.kio.core: couldn’t create worker: “Unknown protocol ‘smb’.” kf.kio.workers.file: readData() returned -1 Konsole output for WEBDAV Connection. QString::arg: 2 argument(s) missing in org.kde.okular kf.kio.widgets: Failed to check which JobView API is supported “org.freedesktop.DBus.Error.ServiceUnknown” kf.kio.workers.http: Can’t communicate with kded_kcookiejar! kf.kio.core: Can’t communicate with kiod_kpasswdserver (for checkAuthInfo)! kf.kio.core: Can’t communicate with kiod_kpasswdserver (for queryAuthInfo)! kf.kio.workers.file: readData() returned -1 EXPECTED RESULT File should open normally regardless of location. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 39 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 Kernel Version: 6.5.12-300.fc39.x86_64 (64-bit) Graphics Platform: Wayland Graphics Processor: AMD Radeon RX 480 Graphics Dolphin Version: 23.08.3 ADDITIONAL INFORMATION
I was getting access denied when opening files in Okular from Dolphin. I solved it by giving Okular permission to talk on DBus session bus org.kde.kcookiejar5
(In reply to tag from comment #1) > I was getting access denied when opening files in Okular from Dolphin. I > solved it by giving Okular permission to talk on DBus session bus > org.kde.kcookiejar5 Okay I just tested adding DBus session access to "org.kde.kcookiejar5" via Flatseal. It still fails to open the remote SMB or WEBDAVS test files. The only thing that changed was that the line "kf.kio.workers.http: Can’t communicate with kded_kcookiejar!" disappeared for me.
Following the lead provided by tag@jthoward.dev, I tested adding a few more Session Bus entry's the Okular flatpak. By adding "org.kde.kcookiejar5", "org.kde.kwalletd5", "org.kde.kpasswdserver" via Flatseal, I am now able to open a PDF with Okular over a WEBDAV connection. The only error still showing up in konsole is: >>kf.kio.widgets: Failed to check which JobView API is supported "org.freedesktop.DBus.Error.ServiceUnknown" These changes do not work for opening the same PDF over an SMB connection. Same errors show up as in my original bug ticket. Sidenote, adding these entries to the Gwenview flatpak do not help with either the WEBDAV or SMB connections.
Hmmmm, could be different issues then. The way i figured out what was wrong was by granting Okular permission for the whole session bus and then running dbus-monitor to see what it was talking on and granting it access one by one until I could open files.
Worth noting I am also running F39 Kinoite (Universal Blue Nvidia specifically) but in an X11 session, haven't really made any significant customizations though
(In reply to tag from comment #5) > Worth noting I am also running F39 Kinoite (Universal Blue Nvidia > specifically) but in an X11 session, haven't really made any significant > customizations though I forgot to add that bug ticket as well. I am running Fedora Kinoite as well. I had Okular and Gwenview in the base image of Fedora Kinoite 38 and everything worked fine. But in Fedora 39, the Fedora KDE SIG removed the applications from the base image because of the their availability via flatpak. Unfortunately, these issues weren't discovered/reported prior to the changes approval.
Feels like a Flatpak packaging issue. In addition to those missing DBus permissions, it feels like maybe the KDE runtime is missing kio-extras or something. Justin, would you be able to take a look?
Out of curiosity, can a flatpak override be used to block the flatpak's internal url interpretation; thereby, forcing the system to accept whatever KIO is offering? Just asking as a temp solution until the flatpak is changed.
I'm also experiencing similar problems with Flatpak packaged KDE Gear apps. KWrite fails for example with “Unable to create KIO worker. Unknown protocol ‘smb’.". I've tried it on Fedora 40, it works with apps installed from RPMs, but not for the Flatpak packaged ones.
Still happening with Okular and Gwenview flatpaks as of 24.08.3. Giving them access to d-bus session bus via flatseal didn't change anything.
FWIW, I've removed the flatpaks, and installed Fedora 41's RPMs of the same version (24.08.3). No problems with opening PDFs and images on smb shares.
I can confirm the issue still exists on our fully patched work machines. Hopefully this gets addressed soon as the workarounds (using alternative apps, CIFS mounting) are a nuisance in a production environment. Okular Version 24.08.3 (flathub) Operating System: Fedora Linux 41 KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0
I found a temporary solution for this, it seems like if you just drop the KDE from Categories in .desktop file, the %U starts resolving as kio-fuse mounted files rather than `smb://...` and the likes. So for example, I copied Okular's desktop file to local applications: > cp ~/.local/share/flatpak/app/org.kde.okular/current/active/export/share/applications/org.kde.okular.desktop ~/.local/share/applications And edited: > -Name=Okular (K) > +Name=Okular > -Categories=Qt;KDE;Graphics;Office;Viewer; > +Categories=Qt;Graphics;Office;Viewer; The name was just to keep track of the changed .desktop entry. After this change to `Categories` Okular started loading image/pdf files from the Samba shares when opening from Dolphin. For reference here is the exec from the Okular's .desktop file: > Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=okular --file-forwarding org.kde.okular @@u %U @@ Not very familiar with KDE/Dolphin codebase but perhaps something triggered by Dolphin opening files has a check for KDE category, and if it sees that category, it then does not resolve the URLs before replacing the %U placeholder. I then tested adding KDE tag to Categories of gThumb: > -Categories=GNOME;GTK;Graphics;Viewer;RasterGraphics;2DGraphics;Photography; > +Categories=GNOME;GTK;KDE;Graphics;Viewer;RasterGraphics;2DGraphics;Photography; And just like that gThumb stopped working, so I am pretty sure there is hard-coded behavior somewhere regarding KDE tag.
In the meantime I created a quick script fix / workaround that has temporarily solved the issue for me on Fedora/Bazzite/Universal-Blue, until a proper fix is created in KDE/Dolphin (this bug report). The script: * Identifies Flatpak KDE applications on your system * Creates modified .desktop files that allow KDE apps to properly handle remote files * Places these modified files in ~/.local/share/applications/flatpak-overrides * Does not modify your original Flatpak installations https://gist.github.com/NonLogicalDev/f518e93aa19d3fc620bae15d388cba58
(In reply to nonlogical from comment #14) > In the meantime I created a quick script fix / workaround that has > temporarily solved the issue for me on Fedora/Bazzite/Universal-Blue, until > a proper fix is created in KDE/Dolphin (this bug report). > > The script: > > * Identifies Flatpak KDE applications on your system > * Creates modified .desktop files that allow KDE apps to properly handle > remote files > * Places these modified files in > ~/.local/share/applications/flatpak-overrides > * Does not modify your original Flatpak installations > > https://gist.github.com/NonLogicalDev/f518e93aa19d3fc620bae15d388cba58 Thank you for your work! I look forward to trying this on my test rig!
> Not very familiar with KDE/Dolphin codebase but perhaps something triggered by Dolphin opening files has a check for KDE category, and if it sees that category, it then does not resolve the URLs before replacing the %U placeholder. Correct. If KIO sees that an application has Category=KDE, it assumes KIO URLs are fully supported and passes them directly. I don't know how flatpak is designed in this regard, but the .desktop files from installed flatpaks probably need some extra treatment either on the flatpak or KIO side.