If you want to install Podman on Fedora 44, you picked the right time to do it. Fedora 44 ships with Podman 6.0 as the default container engine, the biggest architectural shift the project has seen in years.

Podman is a daemonless, rootless container engine built for Linux. It runs containers without a background process owned by root, which means your attack surface is smaller from day one. No daemon means no single point of failure, and no privileged background process sitting on your system while you sleep.

This guide walks you through everything: prerequisites, installation, verification, rootless configuration, running your first container, and troubleshooting the errors that actually show up in the real world. Every command comes with a clear explanation of not just what it does, but why you need to run it.

What Is Podman and Why Fedora 44 Changes the Game

Before you run a single command, it helps to understand what you are actually installing, and what is different about Fedora 44’s version of it.

Podman is an OCI-compatible container engine developed by Red Hat and the open-source community. It manages containers, pods, and images using the same command syntax as Docker, so if you know Docker, you already know most of Podman.

The key difference is architecture. Docker relies on a persistent daemon, dockerd, running as root. Every container you start is a child of that daemon. If the daemon has a vulnerability, an attacker who exploits it gets root access to your entire host. Podman eliminates that model entirely. Each container is a direct child process of the user who started it. If something goes wrong inside a container, the blast radius stops at your user’s permissions.

Podman 6.0, which ships as the default in Fedora 44, introduces several breaking changes that matter whether you are doing a fresh install or upgrading from Fedora 43. Here is what changed and why it affects you:

• BoltDB is gone. SQLite is now the only supported database backend for container state. If you are upgrading from Fedora 43, you must have run podman at least once on Podman 5.8 before upgrading to trigger the automatic database migration. Skip this and your container state becomes unreadable after the upgrade.
• slirp4netns is removed. Pasta (also called passt) is the new default rootless networking backend. Pasta offers better IPv6 support and lower CPU overhead than slirp4netns. Any container configured with --network slirp4netns will fail until you remove that flag.
• cgroups v1 support is dropped completely. Podman 6.0 will not start on a system still using cgroups v1. Fedora 44 uses cgroups v2 by default, but if you are running a customized kernel or an older boot configuration, you need to check this before you install.
• iptables is out, nftables is in. Netavark, Podman’s network management layer, now uses nftables exclusively. If you have manually written iptables rules for your containers, migrate them before installing.

Understanding these changes protects you from spending an hour debugging a problem that has a 30-second fix.

Prerequisites: What You Need Before You Install Podman on Fedora 44

Skipping prerequisites is the most common reason installations fail. Run through this checklist before you touch DNF.

System requirements:

• Fedora 44 installed and running (workstation or server edition both work)
• A user account with sudo access, or direct root access
• An active internet connection for DNF to reach Fedora’s repositories
• Minimum 500MB free disk space (Podman itself is small; images take more space)

Verify your Fedora version first. Podman 6.0 is only the default package on Fedora 44. Installing on Fedora 43 or older will give you Podman 5.x, and the instructions in this guide differ in key places.

cat /etc/os-release

You should see VERSION_ID=44 in the output.

Verify cgroups v2 is active. This is the single most important pre-check for Podman 6.0:

stat -fc %T /sys/fs/cgroup/

The output must read cgroup2fs. If it reads tmpfs, your system is still on cgroups v1, and Podman 6.0 will refuse to start. Fix this by adding systemd.unified_cgroup_hierarchy=1 to your kernel boot parameters via GRUB and rebooting before continuing.

If you are upgrading from Fedora 43 (not a fresh install), do this first:

# Run this before upgrading to ensure SQLite migration happens on Podman 5.8
podman info

This single command triggers the automatic BoltDB-to-SQLite migration. Do it before you run dnf system-upgrade.

Step 1: Update Your System

Every experienced sysadmin runs a full system update before installing new packages. This is not optional.

sudo dnf upgrade --refresh

What this does: dnf upgrade upgrades all installed packages to their latest available versions. The --refresh flag forces DNF to re-download the repository metadata instead of using the local cache.

Why you need it: On a fresh Fedora 44 install, your DNF cache might point to an older Podman 6.0 build. Running --refresh guarantees you pull the latest release. It also resolves potential dependency conflicts between Podman and system libraries before they block the install.

Wait for the upgrade to complete and reboot if the kernel was updated:

sudo reboot

Step 2: Install Podman on Fedora 44

With your system updated, the actual installation takes a single command. Podman lives in Fedora’s default AppStream repository, so no third-party repos are needed.

sudo dnf -y install podman

What this does: dnf install podman pulls Podman and all required dependencies from Fedora’s official repositories. The -y flag auto-confirms the install without prompting.

Why this command is safe to use as-is: Fedora’s AppStream repository is maintained by the Fedora project and Red Hat. You are not adding any third-party source, so the package is signed, verified, and tested against Fedora 44’s exact package set.

DNF will automatically install every dependency Podman 6.0 needs, including:

• netavark: Podman’s network management tool, replaces CNI plugins
• aardvark-dns: DNS server for container networks, paired with Netavark
• crun: The OCI container runtime that actually executes your containers
• conmon: Container monitor process that keeps an eye on each running container
• passt: The Pasta networking backend for rootless containers

You should see output similar to this during the install:

Dependencies resolved.
================================================================================
 Package               Architecture    Version           Repository       Size
================================================================================
Installing:
 podman                x86_64          6.0.x-1.fc44      updates          17 M
Installing dependencies:
 aardvark-dns          x86_64          1.x.x             fedora          2.1 M
 netavark              x86_64          1.x.x             fedora          4.3 M
 crun                  x86_64          1.x.x             fedora          215 k
 passt                 x86_64          ...               fedora          310 k
...
Complete!

If you also plan to use podman machine commands (for example, connecting macOS or Windows clients to this Fedora host), install the optional machine package:

sudo dnf -y install podman-machine

For a standard server or workstation setup, skip this.

Step 3: Verify the Installation

Never assume an install worked just because the command returned no errors. Verification is a three-step process.

Check the Podman Version

podman --version

Expected output:

podman version 6.0.x

If you see version 5.x here, your DNF cache served an older package. Run sudo dnf upgrade --refresh again and check if a newer Podman package is available.

For the full version breakdown:

podman version

This shows the client version, API version, Go runtime version, and OS/architecture. This output is useful when you need to file a bug report or check compatibility with a specific Podman API feature.

Inspect the Full System Stack

podman info

Why this command matters: podman info reveals the complete operational stack, not just the version number. Scan the output for these specific values:

• cgroupVersion: v2 — confirms cgroups v2 is active
• networkBackend: netavark — confirms Netavark is managing container networks
• rootlessNetworkCmd: pasta — confirms Pasta is handling rootless networking
• graphDriverName: overlay — confirms the storage driver is set to overlay
• databaseBackend: sqlite — confirms BoltDB migration completed successfully

If any of these values look wrong, the troubleshooting section below covers the most common causes.

Quick cgroups v2 Confirmation

podman info | grep cgroupVersion

Expected output:

cgroupVersion: v2

If the output reads v1, stop here and fix your cgroups configuration before running any containers. Podman 6.0 does not support cgroups v1.

Step 4: Configure Rootless Containers

This step is where most beginner guides skip a critical detail. Rootless containers are Podman’s biggest security advantage, but they require a few system-level checks to work correctly.

Verify subUID and subGID Mappings

Rootless containers rely on subordinate UID and GID ranges. The kernel uses these ranges to map user IDs inside the container to your host user’s UID range, creating the illusion of root inside the container without actually granting root on the host.

grep $USER /etc/subuid /etc/subgid

Expected output:

/etc/subuid:yourusername:100000:65536
/etc/subgid:yourusername:100000:65536

Fedora 44 creates these entries automatically for users created during installation. If your account was created manually and these lines are missing, add them:

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 $USER

After adding subUID/subGID mappings, reset the Podman namespace so it picks up the new values:

podman system migrate

Enable Lingering for Long-Running Containers

If you plan to run containers as background services under your user account (for example, using Quadlet or Podman’s systemd integration), you need to enable lingering for your user:

sudo loginctl enable-linger $USER

Why this matters: Without linger, your user’s systemd session and all its container processes terminate when you log out. With linger enabled, your user session persists after logout, so containers keep running. This is essential for server deployments where you are not always logged in.

Pasta networking for rootless containers is already active by default in Podman 6.0. You do not need to configure it manually.

Step 5: Run Your First Container

The installation means nothing until you confirm containers actually start, run, and communicate correctly. These three tests cover the full stack from image pull to runtime execution.

Test 1: Basic Echo Container

podman run --rm fedora /bin/echo "Podman 6.0 is running on Fedora 44"

What this does: Podman pulls the official Fedora container image from registry.fedoraproject.org (Fedora’s default registry), creates a container, runs the echo command, prints the output, and then removes the container because of the --rm flag.

Expected output:

Resolved "fedora" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:latest...
Getting image source signatures
Copying blob 4f417555f8f8 done |
Copying config a9005aba99 done |
Writing manifest to image destination
Podman 6.0 is running on Fedora 44

The --rm flag keeps your system clean by removing the container immediately after it exits. For testing and one-off tasks, always use --rm.

Test 2: Interactive Shell Inside a Container

podman run -it fedora /bin/bash

What this does: -i keeps stdin open so you can type commands, and -t allocates a pseudo-TTY so the shell behaves like a real terminal. You drop directly into a Fedora container shell.

You can verify you are inside the container:

cat /etc/os-release

Exit the container when done:

exit

Test 3: Run a Detached Background Container

podman run -itd fedora /bin/bash

The -d flag runs the container as a daemon in the background. Podman prints the full container ID on success. Verify it is running:

podman ps

Expected output:

CONTAINER ID  IMAGE                                    COMMAND     CREATED        STATUS            PORTS       NAMES
b4ff1ebfc489  registry.fedoraproject.org/fedora:latest /bin/bash   5 seconds ago  Up 6 seconds               quirky_moser

Stop and remove the container when you are done:

podman stop <container_id>
podman rm <container_id>

Step 6: Essential Podman Commands for Daily Use

Now that your Fedora 44 setup is complete, here are the commands you will use most often on your Linux server.

# List running containers
podman ps

# List all containers including stopped ones
podman ps -a

# List all downloaded images
podman images

# Pull an image without running it
podman pull docker.io/library/nginx

# View container logs
podman logs <container_id>

# Execute a command inside a running container
podman exec -it <container_id> bash

# Inspect detailed container metadata
podman inspect <container_id>

# Remove all stopped containers, unused images, and networks at once
podman system prune

The podman system prune command is particularly useful on servers where you run many short-lived containers. It reclaims disk space from everything that is no longer in use.

Troubleshooting Common Podman Issues on Fedora 44

Here are the errors that show up most often after a fresh Podman 6.0 install on Fedora 44, along with the exact fix for each one.

Error: Container State Missing or “database is locked”

Symptom: After upgrading from Fedora 43 to Fedora 44, all your previous containers and images have disappeared. Or you see a database-related error when running podman ps.

Root cause: The BoltDB-to-SQLite migration did not complete before you upgraded. Podman 6.0 cannot read the old BoltDB state file.

Fix:

# This is destructive. It wipes all container state.
podman system reset

To prevent this in the future: after any Fedora upgrade that bumps the Podman minor version, run podman info once before rebooting into the next major version.

Error: “pasta failed” or Rootless Network Not Working

Symptom: Rootless containers start but have no network access. Or you see an error mentioning pasta during container startup.

Root cause: The passt package may not have installed correctly, or a configuration conflict is pointing to slirp4netns which no longer exists.

Fix:

# Reinstall the passt package
sudo dnf reinstall passt

# Verify pasta is available
which pasta

If you have containers explicitly using --network slirp4netns, remove that flag. Pasta handles rootless networking automatically without any flags in Podman 6.0.

Error: “cgroups v1 is not supported”

Symptom: Podman installs but fails immediately when you run any container with a cgroups-related error.

Root cause: Your system is booting with cgroups v1 hierarchy. Podman 6.0 will not run on cgroups v1.

Fix:

# Check your current grub configuration
sudo cat /etc/default/grub

# Add the cgroups v2 parameter to GRUB_CMDLINE_LINUX
sudo nano /etc/default/grub
# Add: systemd.unified_cgroup_hierarchy=1 inside the GRUB_CMDLINE_LINUX quotes

# Regenerate GRUB config
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# Reboot
sudo reboot

After rebooting, verify cgroups v2 is active: stat -fc %T /sys/fs/cgroup/ should return cgroup2fs.

Error: “permission denied” When Binding to Port 80 or 443

Symptom: Your rootless container fails to start because it cannot bind to a privileged port below 1024.

Root cause: Linux reserves ports below 1024 for root by default. A rootless Podman container runs as your user, not root, so the kernel blocks the bind.

Fix (temporary, resets on reboot):

sudo sysctl net.ipv4.ip_unprivileged_port_start=80

Fix (permanent):

echo "net.ipv4.ip_unprivileged_port_start=80" | sudo tee /etc/sysctl.d/99-unprivileged-port.conf
sudo sysctl --system

A better long-term approach for production: run your container on port 8080 internally and use a reverse proxy like Nginx or Caddy on the host to forward port 80 traffic to it.

Error: Image Platform Mismatch Warning

Symptom: Container pulls but throws a warning like image platform (linux/arm64) does not match the expected platform (linux/amd64), or fails to start entirely.

Root cause: You pulled an image built for a different CPU architecture. This usually happens on ARM-based machines when pulling x86-only images, or vice versa.

Fix: Explicitly specify the correct platform when pulling:

podman pull --platform linux/amd64 docker.io/library/nginx

Or build a multi-architecture image using podman buildx if you control the image source.

Congratulations! You have successfully installed Podman. Thanks for using this tutorial for installing Podman containers on your Fedora 44 Linux system. For additional help or useful information, we recommend you check the official Podman website.