Install Flatpak and Flathub Apps on Fedora 45 / 44

You want Obsidian, OBS Studio or a newer VLC on Fedora, and the RPM is missing, stale or stuck behind a third-party repo. Flatpak is the clean way around that, and a Fedora 45 Workstation install already has it wired up with two app sources. The catch is that those two sources overlap, the sandbox defaults are looser than most people assume, and a few commands behave differently over SSH than in a desktop terminal. I ran the whole workflow on a Fedora 45 Workstation box and a Fedora 44 machine, and this guide sticks to what those two did.

Original content from computingforgeeks.com - post 167766

Ran all of this on a Fedora 45 Workstation box in October 2026, and rechecked the install, Flathub setup and update timer on a Fedora 44 machine. Flatpak 1.18.4 on both.

1. Check what Fedora already set up

Workstation ships the flatpak package and two system-wide remotes out of the box. Check the version and the remotes first:

flatpak --version
flatpak remotes --columns=name,title,options,filter

On the Fedora 45 Workstation box both remotes were there before I touched anything:

Flatpak 1.18.4
fedora	Fedora Flatpaks	system,oci	-
flathub	Flathub	system,filtered	/usr/share/flatpak/fedora-flathub.filter

Two things in that output trip people up, starting with fedora, which is Fedora’s own Flatpak registry served as OCI images from registry.fedoraproject.org and rebuilt from Fedora RPMs. flathub is the upstream Flathub repo, and it shows as filtered. That looks like a restricted Flathub, but the filter file Fedora ships is empty:

cat /usr/share/flatpak/fedora-flathub.filter

The whole file is one comment line:

# Unfiltered

So you get the full Flathub catalogue. The filter hook stays so Fedora can narrow the list later without replacing the remote. This is the same check on the Workstation box:

The rpm -q flatpak version string on Fedora 45 reads flatpak-1.19.0^really1.18.4, which looks odd but is just packaging. The ^really suffix is a packaging trick that took Fedora 45 back from a 1.19 development build to the stable 1.18 series without bumping the Epoch, and flatpak --version reports 1.18.4.

Server, Cloud and minimal installs

Server and Cloud images do not ship Flatpak at all, so on the Fedora 44 Cloud VM I installed it and added Flathub by hand:

sudo dnf install -y flatpak
sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak remotes --columns=name,title,options,filter

That box has no Fedora remote and no filter, just a plain Flathub:

Flatpak 1.18.4
flathub	Flathub	system	-

Here is how the two releases compared on the lab machines:

Item	Fedora 45 Workstation	Fedora 44 Cloud
Flatpak	1.18.4 (package 1.19.0^really1.18.4)	1.18.4
Remotes out of the box	fedora (OCI) and flathub	None until you add Flathub
Flathub filter	/usr/share/flatpak/fedora-flathub.filter, empty	None
GNOME Software	51.0	Not installed

2. Fedora Flatpaks or Flathub?

The two remotes are very different in size. I counted the apps in each (I ran these over a non-interactive SSH session, where the Fedora count needs sudo, more on that in the troubleshooting section):

flatpak remote-ls --app flathub | wc -l
sudo flatpak remote-ls --app fedora | wc -l

Flathub listed 3,477 apps and Fedora Flatpaks 523. Popular apps such as Flatseal and Inkscape show up in both, and flatpak search tells you which remotes carry each one:

flatpak search --columns=name,application,version,remotes inkscape

The last column lists every remote that carries it:

Inkscape	org.inkscape.Inkscape	1.4.4	fedora,flathub

The bigger difference is the runtime underneath. Fedora Flatpaks run on org.fedoraproject.Platform, and on Fedora 45 that runtime is still the f44 branch. Flathub apps use the Freedesktop, GNOME or KDE runtimes. Mix the two and you end up downloading both stacks of runtimes. When I installed Flatseal from Flathub and then switched it to the Fedora build, /var/lib/flatpak grew from 2.8 GB to 5.7 GB for the same 1 MB app, mostly the Fedora runtime plus its 2 GB locale extension.

My rule: pick one source per app and stay on it. On a desktop I lean on Flathub, because that’s where vendors publish (Obsidian, Bitwarden, OBS) and it’s what the upstream bug trackers expect. GNOME Software leans the other way. Its preference list puts Fedora Flatpaks ahead of RPMs, and Flathub is not on the list at all:

gsettings get org.gnome.software packaging-format-preference

On a fresh Fedora 45 Workstation it returns Fedora’s own sources first:

['flatpak:fedora-testing', 'flatpak:fedora', 'rpm']

If you want Flathub only, disable the Fedora remote. Already installed Fedora Flatpaks keep working, but their updates are skipped silently, with no warning in flatpak update:

sudo flatpak remote-modify --disable fedora
flatpak search --columns=application,remotes inkscape

Search then only returns the Flathub build:

org.inkscape.Inkscape	flathub

Turn it back on with sudo flatpak remote-modify --enable fedora.

The verified FLOSS subset for Fedora Atomic desktops

FESCo accepted the Filter Fedora Flatpaks for Atomic Desktops v2 change for Fedora 45, but the filter had not landed by late September and the tracker expects it to slip to Fedora 46. Once it ships, it is opt-in per image-based desktop: an edition such as Silverblue can choose to enable only Flathub’s verified, free-software subset by default, and it then filters the Fedora Flatpak remote down to the pre-installed apps and their runtimes. Workstation, the edition I tested, still gets the full Flathub. You can add that subset as its own remote on any Fedora to see what it leaves out:

sudo flatpak remote-add --if-not-exists --subset=verified_floss --title="Flathub verified FLOSS" flathub-vf https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak remote-ls --system --app flathub-vf | wc -l

The subset listed 2,046 apps against 3,477 for the full remote. Checking a few common picks by app ID:

com.spotify.Client         full:1 verified_floss:0
com.discordapp.Discord     full:1 verified_floss:0
com.valvesoftware.Steam    full:1 verified_floss:0
us.zoom.Zoom               full:1 verified_floss:0
md.obsidian.Obsidian       full:1 verified_floss:0
org.videolan.VLC           full:1 verified_floss:0
com.obsproject.Studio      full:1 verified_floss:1
com.bitwarden.desktop      full:1 verified_floss:1

Proprietary apps drop out as you’d expect, and so does VLC, even though it’s free software. Check an app’s Flathub page for the verified badge if you plan to run the subset. Remove the test remote with sudo flatpak remote-delete flathub-vf.

3. Install an app from GNOME Software

Open Software, search, and pick the app. The search results mix RPMs, Fedora Flatpaks and Flathub apps in one list:

On the app page, the button under Install shows the source. Click it to see the choices. For Obsidian the only one is Flathub, labelled as a Flatpak from dl.flathub.org:

I clicked Install and it did not ask for a password, which is by design. Flatpak ships a polkit rule (built with wheel as the privileged group on Fedora) that lets members of that group install and remove Flatpaks without a prompt, but only from an active local session:

cat /usr/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules

The first rule is the one that matters:

polkit.addRule(function(action, subject) {
    if ((action.id == "org.freedesktop.Flatpak.app-install" ||
         action.id == "org.freedesktop.Flatpak.runtime-install"||
         action.id == "org.freedesktop.Flatpak.app-uninstall" ||
         action.id == "org.freedesktop.Flatpak.runtime-uninstall" ||
         action.id == "org.freedesktop.Flatpak.modify-repo") &&
        subject.active == true && subject.local == true &&
        subject.isInGroup("wheel")) {
            return polkit.Result.YES;
    }

    return polkit.Result.NOT_HANDLED;
});

Outside that rule, the defaults in /usr/share/polkit-1/actions/org.freedesktop.Flatpak.policy apply, which means admin authentication for each action. That is why SSH behaves so differently, as step 4 shows.

To see or toggle the sources Software uses, open the menu and pick Software Repositories. Flathub sits under Fedora Third Party Repositories, next to the Chrome and RPM Fusion NVIDIA and Steam repos, so turning off third-party repos in the first-boot wizard also turns off Flathub:

If you skipped third-party repos during setup, the toggle in that dialog brings them back. From a terminal, sudo fedora-third-party enable does the same thing, but it turns on every third-party repo (Chrome, Steam, NVIDIA and the rest), not just Flathub, and it only restores a Flathub remote that it added itself. If you deleted the remote, add it back with flatpak remote-add.

4. Install apps from the command line

From a desktop terminal, a wheel user can install system-wide without sudo or a password. Over SSH the polkit rule above doesn’t apply. Run flatpak install interactively, without -y, and it asks you in the terminal to pick an identity and type your password:

==== AUTHENTICATING FOR org.freedesktop.Flatpak.metadata-update ====
Authentication is required to update metadata
Multiple identities can be used for authentication:
 1.  Sys Admin (sysadmin)
 2.  kibet
Choose identity to authenticate as (1-2): 2
Password: 
==== AUTHENTICATION COMPLETE ====

It asks again for every privileged step. Installing GNOME Calculator with its runtime took ten password prompts over SSH before it finished. Add -y and the system helper is told not to ask, so nothing prompts at all. The install downloads everything and then fails at the deploy step with “not allowed for user” (see troubleshooting). Over SSH, sudo is the sane option, so the commands below use it. Name the remote and the app ID:

sudo flatpak install -y flathub com.github.tchx84.Flatseal

The first Flathub app is the expensive one. Flatseal itself is 1.4 MB, but it pulled the GNOME 50 runtime, Mesa and a codecs extension, and /var/lib/flatpak went from empty to 1.9 GB in 62 seconds. The list shows where the space went:

flatpak list --columns=name,application,version,branch,origin,installation,size

Five entries for one small app:

Flatseal	com.github.tchx84.Flatseal	2.4.1	stable	flathub	system	1.4 MB
Mesa	org.freedesktop.Platform.GL.default	26.2.2	25.08	flathub	system	462.4 MB
Mesa (Extra)	org.freedesktop.Platform.GL.default	26.2.2	25.08-extra	flathub	system	462.4 MB
Codecs Extra Extension	org.freedesktop.Platform.codecs-extra		25.08-extra	flathub	system	43.4 MB
GNOME Application Platform version 50	org.gnome.Platform		50	flathub	system	1.1 GB

A second app on the same runtime costs only its own size. An app on a different runtime pays again. VLC uses the KDE 5.15 runtime, and before it installs Flatpak prints the sandbox permissions the app asks for (I trimmed the progress bars from this output):

sudo flatpak install -y flathub org.videolan.VLC

The runtime check and the permissions list come before the download plan:

Required runtime for org.videolan.VLC/x86_64/stable (runtime/org.kde.Platform/x86_64/5.15-25.08) found in remote flathub

org.videolan.VLC permissions:
    ipc	network	pulseaudio	x11
    devices	file access [1]	dbus access [2]	bus ownership [3]

    [1] host, xdg-config/kdeglobals:ro, xdg-run/gvfs
    [2] com.canonical.AppMenu.Registrar, org.freedesktop.PowerManagement,
        org.freedesktop.ScreenSaver, org.freedesktop.secrets,
        org.kde.KGlobalSettings, org.kde.StatusNotifierWatcher,
        org.kde.kconfig.notify, org.kde.kwalletd, org.kde.kwalletd5,
        org.mpris.MediaPlayer2.Player
    [3] org.mpris.MediaPlayer2.vlc


 1.	   	org.kde.KStyle.Adwaita	5.15-25.08	i	flathub	< 6.6 MB
 2.	   	org.kde.Platform.Locale	5.15-25.08	i	flathub	< 400.3 MB (partial)
 3.	   	org.kde.Platform	5.15-25.08	i	flathub	< 367.4 MB
 4.	   	org.videolan.VLC.Locale	stable	i	flathub	< 14.7 MB (partial)
 5.	   	org.videolan.VLC	stable	i	flathub	< 52.7 MB


Installation complete.

Read that permissions block before you hit enter. file access [1] includes host, which means VLC can read and write your whole home directory and most of the filesystem. That’s normal for a media player, and it’s also why “Flatpak is sandboxed” is only partly true. Step 6 shows how to tighten it.

The permission list comes from the app’s own manifest, and Flatpak grants all of it unless you override it.

After VLC the store was 2.8 GB. Run an installed app by its ID, or just launch it from the Activities overview:

flatpak run org.videolan.VLC

5. System installs vs user installs

Flatpak has two installation scopes. System installs live in /var/lib/flatpak and every account on the machine shares them. User installs live in ~/.local/share/flatpak and need no admin rights. Fedora only defines its remotes at system level, so a user install fails until you add Flathub for your own account:

flatpak install --user -y flathub org.gnome.Calculator

On a stock install, that fails straight away:

error: No remote refs found for ‘flathub’

Add the remote with --user and the install works:

flatpak remote-add --user --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak install --user -y flathub org.gnome.Calculator

It took two minutes and 2.6 GB of home directory space for a 5 MB calculator, because Calculator wants the GNOME 51 runtime and the newer Freedesktop extensions, and none of those were installed system-wide. A user install does reuse a matching system runtime when one exists. There’s a second side effect. With flathub defined twice, any command that names the remote has to pick a scope:

flatpak remote-info --log flathub org.videolan.VLC

With Flathub in both scopes, Flatpak refuses to guess:

Remote ‘flathub’ found in multiple installations:

   1) system
   2) user

Which do you want to use (0 to abort)? [0-2]: 0
error: No remote chosen to resolve ‘flathub’ which exists in multiple installations

Add --system or --user and it goes through, but on a single-user laptop I’d skip user installs entirely. They make sense on a shared machine where you are not in wheel. To back out:

flatpak uninstall --user -y --all
flatpak remote-delete --user flathub

6. Lock down sandbox permissions with flatpak override

Start by checking what an app actually gets from its manifest before you change anything:

flatpak info --show-permissions org.videolan.VLC

VLC’s manifest asks for this much:

[Context]
shared=ipc;network;
sockets=pulseaudio;x11;
devices=all;
filesystems=xdg-config/kdeglobals:ro;host;xdg-run/gvfs;

To prove what filesystems=host means, I made a dummy file in ~/Documents and a clip in ~/Videos, then listed them from inside the VLC sandbox:

flatpak run --command=ls org.videolan.VLC ~/.ssh ~/Documents ~/Videos

VLC sees everything in those folders, SSH keys included:

/home/kibet/.ssh:
authorized_keys

/home/kibet/Documents:
notes.txt

/home/kibet/Videos:
clip.mkv

Now take host away and grant only the Videos folder, read-only. --user keeps the override in your home directory, so it applies to your account only:

flatpak override --user --nofilesystem=host --filesystem=xdg-videos:ro org.videolan.VLC
flatpak override --user --show org.videolan.VLC

The override is a small keyfile under ~/.local/share/flatpak/overrides/:

[Context]
filesystems=xdg-videos:ro;!host;

Run the same listing again, plus a write test into the Videos folder:

flatpak run --command=ls org.videolan.VLC ~/.ssh ~/Documents ~/Videos
flatpak run --command=touch org.videolan.VLC ~/Videos/new.mkv

~/.ssh and ~/Documents no longer exist inside the sandbox, and Videos is read-only:

/home/kibet/Videos:
clip.mkv
ls: cannot access '/home/kibet/.ssh': No such file or directory
ls: cannot access '/home/kibet/Documents': No such file or directory
touch: cannot touch '/home/kibet/Videos/new.mkv': Read-only file system

The whole before and after, override included, fits in one terminal:

This trips people up: a media player that cannot write to Videos cannot save snapshots or recordings there either, so test the app’s own features after you lock it down. Undo everything for that app with:

flatpak override --user --reset org.videolan.VLC

If you’d rather click than type, install Flatseal (com.github.tchx84.Flatseal). It reads and writes the same override files and shows every permission as a toggle. This is VLC’s filesystem section with host switched on:

7. Update, roll back and pin apps

On Workstation, GNOME Software handles Flatpak updates in the background (org.gnome.software download-updates is true by default). From the CLI:

sudo flatpak update -y

There’s no Flatpak update timer on Fedora, so a box without GNOME Software never updates Flatpaks unless you do it. On the Fedora 44 Cloud VM I used a small systemd service and timer. Save this as /etc/systemd/system/flatpak-update.service:

[Unit]
Description=Update system Flatpaks
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/bin/flatpak update --system --noninteractive
ExecStart=/usr/bin/flatpak uninstall --system --unused --noninteractive

And this as /etc/systemd/system/flatpak-update.timer:

[Unit]
Description=Update system Flatpaks daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=1h
Persistent=true

[Install]
WantedBy=timers.target

Enable it, then fire the service once to check it works:

sudo systemctl daemon-reload
sudo systemctl enable --now flatpak-update.timer
sudo systemctl start flatpak-update.service
sudo journalctl -u flatpak-update.service --no-pager -o cat | tail -8

The test run refreshed Flathub’s appstream data, found nothing to remove and exited cleanly:

security: SIGN: disabled http: TLS
delta: parts: 2 loose: 4
transfer: secs: 6 size: 47.2 MB
system: Pulled appstream2/x86_64 from flathub
Nothing unused to uninstall
flatpak-update.service: Deactivated successfully.
Finished flatpak-update.service - Update system Flatpaks.
flatpak-update.service: Consumed 2.701s CPU time over 8.881s wall clock time, 155.4M memory peak.

I tested this timer on a Flathub-only box. A root process has no D-Bus session bus, and the troubleshooting section shows Fedora’s OCI remote failing without one, so on a machine that keeps Fedora Flatpaks installed I’d start both ExecStart lines with /usr/bin/dbus-run-session. That binary comes from the dbus-daemon package, which Workstation has and the Cloud image does not, so install it first on Server or Cloud.

Roll back a bad update

Every Flathub app update is an OSTree commit, and you can go back to an older one. List the history for the app:

flatpak remote-info --system --log flathub org.videolan.VLC | head -30

The top of the output shows the current commit, followed by older ones with their dates:

        Commit: 5e38b439b73601ed51c3a911b04c6b233d9fa6fdfd8ad1381585c37af3f79f7d
        Parent: 3cad91eaf629cfc8afb5085613ba4569ccf674ac62ae650583aac34aeaec0038
       Subject: Update libass, x265, ffmpeg and smbclient modules (#316) (144698b854c1)
          Date: 2026-07-18 00:59:10 +0000
       History: 

        Commit: 3cad91eaf629cfc8afb5085613ba4569ccf674ac62ae650583aac34aeaec0038
       Subject: Update ffmpeg and smbclient modules (#307) (a5b9fa9a8c33)
          Date: 2026-05-12 23:42:24 +0000

        Commit: de98ec3b4066f7428620128da1612641b05a2f59d13326a89c84bbaca7577d62
       Subject: Update libupnp, smbclient and srt modules (#305) (75ee08de342c)
          Date: 2026-05-03 14:46:23 +0000

Deploy the previous commit, then check what’s installed:

sudo flatpak update -y --system --commit=3cad91eaf629cfc8afb5085613ba4569ccf674ac62ae650583aac34aeaec0038 org.videolan.VLC
flatpak info --system org.videolan.VLC | grep -E "Version|Commit|Parent|Date"

The downgrade took 22 seconds, and the info output confirms the older commit:

       Version: 3.0.23
        Commit: 3cad91eaf629cfc8afb5085613ba4569ccf674ac62ae650583aac34aeaec0038
        Parent: de98ec3b4066f7428620128da1612641b05a2f59d13326a89c84bbaca7577d62
          Date: 2026-05-12 23:42:24 +0000

Skip the next step and the next flatpak update (or GNOME Software) puts you straight back on the broken build. Mask the app to pin it:

sudo flatpak mask --system org.videolan.VLC
sudo flatpak update -y --system

With the mask in place the update run left VLC alone:

Nothing to update.

The rollback and the pin together, as they ran on the lab box:

Remove the mask when a fixed build lands, and the next update brings the app current again:

sudo flatpak mask --system --remove org.videolan.VLC

8. Remove apps and reclaim space

Uninstalling an app leaves its runtimes behind. Clean up anything no longer used:

sudo flatpak uninstall -y --unused

On my box I ran it right after moving Flatseal to the Fedora build (step 9 covers that), so nothing needed the GNOME 50 runtime and its locale any more:

 1.	   	org.gnome.Platform	50	r
 2.	   	org.gnome.Platform.Locale	50	r
 3.	   	org.freedesktop.Platform.codecs-extra	25.08-extra	r


Uninstall complete.

App data lives under ~/.var/app/<app-id>, and --delete-data is supposed to remove it. It only does that for the user who runs the command. I uninstalled VLC with sudo flatpak uninstall -y --delete-data org.videolan.VLC over SSH, and the app went away but ~/.var/app/org.videolan.VLC was still there, because sudo ran the cleanup as root, against /root/.var/app. It also printed error: Cannot autolaunch D-Bus without X11 $DISPLAY after “Uninstall complete.” while trying to reset the app’s portal permissions. Running the same thing without sudo from the desktop terminal removed both the app and its data folder:

flatpak uninstall -y --delete-data md.obsidian.Obsidian

If the data survives, delete it by hand with rm -rf ~/.var/app/org.videolan.VLC.

9. Move an app from Fedora Flatpaks to Flathub

--reinstall looks like the right tool for switching an app’s source. It worked from Flathub to Fedora, but the other way round it failed partway through:

sudo flatpak install -y --reinstall flathub com.github.tchx84.Flatseal

Flatpak stopped with:

error: Failed to install com.github.tchx84.Flatseal: While pulling app/com.github.tchx84.Flatseal/x86_64/stable from remote flathub: Update is older than current version

The Fedora build had a newer commit timestamp than the Flathub one, so Flatpak saw the switch as a downgrade and refused. It had already pulled the GNOME runtime by then, which stayed installed. Uninstall first, then install from the remote you want:

sudo flatpak uninstall -y com.github.tchx84.Flatseal
sudo flatpak install -y flathub com.github.tchx84.Flatseal
sudo flatpak uninstall -y --unused

The last command removed the four Fedora runtime pieces the app no longer needed, and /var/lib/flatpak went back down to 2.8 GB.

Troubleshooting

These are the errors I hit on the two lab boxes, each with the fix that worked for me.

Flatpak system operation Deploy not allowed for user

Running a system install non-interactively over SSH without sudo fails for every ref:

F: Failed to get revokefs-fuse socket from system-helper: Flatpak system operation GetRevokefsFd not allowed for user
Warning: Failed to install org.freedesktop.Platform.GL.default: Flatpak system operation Deploy not allowed for user

flatpak remote-ls fedora fails the same way with GenerateOciSummary not allowed for user. SSH sessions are not local, so the wheel rule does not apply and polkit wants your password. When nothing can ask for it (-y, --noninteractive, ssh host 'command' without a TTY, cron), the request is refused. Use sudo, install with --user, run it interactively without -y, or run the command from a terminal on the desktop. The GUI version of this error is Unable to install: permission required, which I got from a GNOME Software window started over SSH. Launching Software from the desktop fixed it.

Cannot autolaunch D-Bus without X11 $DISPLAY

This one hit the Fedora OCI remote. sudo flatpak install fedora ... pulled the runtimes and then failed on the app, because Flatpak’s OCI authenticator needs a D-Bus session bus and sudo drops yours. Give it a throwaway bus (on Server or Cloud, install dbus-daemon first for dbus-run-session):

sudo dbus-run-session flatpak install -y fedora com.github.tchx84.Flatseal

No remote refs found for ‘flathub’

You ran --user and Flathub is only defined at system level. Add it with flatpak remote-add --user as shown in step 5, or drop --user.

Remote ‘flathub’ found in multiple installations

Flathub is defined at both system and user level, and the command didn’t say which one to use. Add --system or --user, or delete the user remote if you don’t need it.

Where Flatpak fits next to RPM and Toolbx

I keep system tools, drivers and anything that hooks into the host as RPMs (RPM Fusion covers codecs and the NVIDIA stack). GUI apps from upstream vendors go on Flathub, and CLI dev environments live in containers, which the Distrobox vs Toolbx comparison covers. If you’re still weighing the formats, the Snap vs Flatpak vs AppImage breakdown lays out the trade-offs, and running AppImages on Fedora covers the FUSE package that format still needs. For the rest of a new install, see the things to do after installing Fedora 45 checklist and the dnf5 cheatsheet for the RPM side of the system.