How to Install and Use Podman on Ubuntu 24.04

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.

On Ubuntu 24.04, install Podman from Ubuntu’s standard repositories with sudo apt-get update followed by sudo apt-get -y install podman. Verify the installation with podman --version and podman info, then run podman run -it hello as a first test. Podman is daemonless for normal command-line use, so no background service is required just to create and run containers.

This guide covers everyday container commands, rootless operation without sudo, the differences between rootless and rootful state, persistent services with Quadlet and systemd, and the optional API socket.

What you need before installing

You need a working Ubuntu 24.04 installation, an account that can use sudo, and network access to download packages and container images. The commands below use Ubuntu’s packaged Podman rather than a third-party repository. Podman’s installation documentation lists Ubuntu 20.10 and newer as supported by this package route, which includes Ubuntu 24.04.

• Log in to the Ubuntu machine locally or over SSH.
• Confirm that your account has administrative privileges through sudo.
• Make sure DNS and outbound HTTPS access work if you intend to pull images from a registry.
• Keep enough disk space for image layers, writable container layers, and any volumes you create.

The exact Podman package revision in the Ubuntu 24.04 archive can change as Ubuntu publishes updates. Do not assume a particular version number; check the version installed on your machine.

Install Podman from Ubuntu’s repositories

1. Refresh the package index

1. Open a terminal.
2. Run:

   sudo apt-get update

3. Enter your password when prompted. The command downloads current package metadata; it does not install Podman yet.

2. Install the package

Install Podman with:

sudo apt-get -y install podman

The -y option accepts apt’s confirmation prompt automatically. Omit it if you want to review the proposed package changes before confirming.

3. Check the installed build

When apt finishes, run:

podman --version

This reports the version supplied by your enabled Ubuntu repositories. If a command behaves differently from examples written for another release, consult the help shipped with your installation:

podman --help

Podman’s normal CLI does not require you to start a daemon or enable a service. The client creates and manages containers directly in the selected user context.

Check the host configuration

Use podman info to inspect the storage driver, image store, runtime, networking configuration, cgroup version, and whether the command is running rootless or rootful:

podman info

Review this output before troubleshooting. It tells you which user owns the current container store and which runtime and networking components your package selected. Optional helpers can vary with the Ubuntu package and configuration, so use the reported configuration rather than installing legacy networking or storage packages from an unrelated guide.

Run your first container

A minimal smoke test

Run the small test image with:

podman run -it hello

Podman downloads the image if it is not already present, creates a container, attaches your terminal, and runs the image’s default process. The exact output comes from the image, but a successful command confirms that the client, local storage, runtime, networking setup, and registry access are working together.

Run a web container

To start an NGINX web server in the background and publish it on port 8080 of the host, run:

podman run -d --name web -p 8080:80 docker.io/library/nginx:alpine

• -d detaches the process and leaves the container running in the background.
• --name web assigns a stable, readable container name instead of relying on an automatically generated name.
• -p 8080:80 maps host TCP port 8080 to port 80 in the container.
• docker.io/library/nginx:alpine identifies the image and tag explicitly.

Open http://localhost:8080 on the Ubuntu host, or use the host’s address from another machine if its firewall allows the port. Binding to a host port does not by itself open that port through an external firewall.

Inspect and control containers

List containers

Show only currently running containers:

podman ps

Include containers that have exited:

podman ps -a

A stopped container remains in the local store until you remove it. This is useful when you need to inspect its exit status or logs.

Read logs and inspect state

Display output captured from the web container:

podman logs web

Inspect detailed metadata, including mounts, environment, networking, and the image used:

podman inspect web

If the image contains a shell and you need an interactive session, start a process inside the running container with:

podman exec -it web sh

The available shell depends on the image. Minimal images may provide sh but not bash.

Stop, restart, and remove

Stop the running web container:

podman stop web

Start the same stopped container again:

podman start web

Remove it after it has stopped:

podman rm web

Remove an image that is no longer needed:

podman rmi docker.io/library/nginx:alpine

Podman will refuse to remove an image that is still referenced by containers. Remove or replace those containers first, and verify the image name with podman images.

Understand images, containers, networks, and volumes

Podman manages four related types of objects:

• Images: Immutable templates made of layers. Pulling an image stores those layers locally.
• Containers: Runnable instances created from images. Their writable changes belong to that container unless you mount persistent storage.
• Networks: Connectivity configurations that let containers communicate with each other and with the host.
• Volumes: Named storage locations intended to keep application data independently of a container’s lifecycle.

A container’s writable layer is not a substitute for a backup. If you remove and recreate the container without a volume, data written only inside that layer can be lost. For stateful applications, create and mount a named volume, and define how it will be backed up before putting the service into production.

Use the installed command help for object-specific operations:

podman image --help
podman container --help
podman network --help
podman volume --help

Use Podman without sudo (rootless containers)

Rootless Podman runs under your ordinary Linux account and uses a user namespace. It avoids running the CLI as host root and is the usual choice for development and services that do not need privileged host resources.

Check subordinate UID and GID mappings

Rootless containers require subordinate user and group ranges recorded in /etc/subuid and /etc/subgid. Inspect the current entries first:

grep "^$(id -un):" /etc/subuid
grep "^$(id -un):" /etc/subgid

If your account has no suitable range, add one with the account name substituted for USERNAME:

sudo usermod --add-subuids 10000-75535 USERNAME
sudo usermod --add-subgids 10000-75535 USERNAME

Do not append a duplicate range if entries already exist. A range must not overlap another account’s allocation. After changing these files, start a new login session so the account and its user services use the updated settings.

Run and verify a rootless container

Without sudo, run:

podman run -d --name rootless-web -p 8080:80 docker.io/library/nginx:alpine
podman ps
podman info

The root identity displayed inside a rootless container is mapped to the invoking host user by default. It is not equivalent to unrestricted host-root access.

Rootless limitations to plan for

Rootless operation cannot automatically perform every host-level action available to root. Depending on your kernel, package configuration, and security policy, you may encounter restrictions involving privileged ports, device access, low-level networking, or mounts. Choose a higher unprivileged host port such as 8080 for development, and grant only the specific device or capability an application genuinely requires.

Rootless versus rootful Podman

Running podman and running sudo podman select different stores and security contexts. A container created by your normal account is not listed by root’s Podman, and a root-created container is not listed by your account.

Operating choice	Who owns the process and store	Typical advantages	Important considerations
Rootless	Your Linux user; user-scoped images and containers	Does not require host-root CLI access; limits the impact of mistakes to the user context	Some privileged ports, devices, mounts, and networking features may be unavailable; user systemd manages persistent services
Rootful	Host root; system-wide container and image state	Suitable for host administration and workloads that need privileged resources	Commands require sudo; a mistake affects the host-root context; rootless containers remain invisible

When a container appears to be missing, first check whether you created it as another user. Compare podman ps -a with sudo podman ps -a; the difference is expected, not evidence that the container was deleted.

Keep a container running with Quadlet and systemd

For a one-off test, podman run is direct and convenient. For a service that should be described declaratively and started, stopped, and monitored by systemd, use Quadlet. Quadlet files describe containers, pods, images, networks, volumes, or Kubernetes YAML deployments; a systemd generator turns them into service units. Quadlet requires cgroup v2.

Create a rootless Quadlet file

Make the per-user configuration directory and create web.container:

mkdir -p ~/.config/containers/systemd
nano ~/.config/containers/systemd/web.container

Put this content in the file:

[Container]
Image=docker.io/library/nginx:alpine
ContainerName=web
PublishPort=8080:80

The filename basename, web, determines the generated service name, web.service. Quadlet keys are release-specific, so check the manual installed with your package when adding mounts, environment variables, dependencies, health checks, or restart behavior.

Reload and start the generated service

After creating or editing the file, reload the user systemd manager and start the generated unit:

systemctl --user daemon-reload
systemctl --user start web.service
systemctl --user status web.service

Edit the Quadlet source file when you need to change the container definition. Do not edit a generated service unit; regeneration can overwrite such changes.

Run a user service after reboot

A user systemd manager normally depends on a login session. If the service must be available after reboot without an active login, enable lingering for the account:

sudo loginctl enable-linger USERNAME

Replace USERNAME with the account that owns the Quadlet file. This is separate from enabling the container itself; the Quadlet unit still needs to be started or configured according to your systemd workflow.

Rootful Quadlet files

Administrator-managed rootful Quadlet definitions commonly live in /etc/containers/systemd/ and are controlled by the system systemd manager. Rootless definitions belong under the user’s ~/.config/containers/systemd/. Keep the file location, image ownership, and systemd scope consistent; mixing a rootless definition with rootful commands is a frequent source of confusion.

Use the Podman API socket only when needed

Most local Podman commands do not need an API service. Start a socket only when another client specifically requires Podman’s Docker-compatible API.

Rootless socket

The documented rootless endpoint is:

unix://$XDG_RUNTIME_DIR/podman/podman.sock

Start the user socket with:

systemctl --user start podman.socket

Rootful socket

The rootful endpoint is:

unix:///run/podman/podman.sock

Start it with:

sudo systemctl start podman.socket

For a user socket that must remain available after reboot without an active login, enable lingering for that account as described in the Quadlet section.

Do not expose an unauthenticated TCP socket

A Unix socket is the documented default and is protected by the corresponding user or root permissions. An unauthenticated TCP endpoint would let anyone who can reach it request substantial container control. Do not bind the API to a network interface as a convenience shortcut; use the local Unix socket and an explicitly configured, authenticated proxy if remote access is genuinely required.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Troubleshoot common problems

podman: command not found

Confirm that apt completed successfully and that the package is installed:

apt-cache policy podman
dpkg -s podman

If the package is not installed, run sudo apt-get update and repeat the installation. If it is installed but the shell cannot find it, start a new shell and check command -v podman.

The image pull fails

• Check DNS and outbound HTTPS connectivity.
• Run podman info to see the configured registries and storage.
• Use a fully qualified image reference such as docker.io/library/nginx:alpine instead of relying on short-name resolution.
• Try the command as the same user that will own the container; rootless and rootful image stores are separate.

Rootless setup reports a mapping error

Inspect /etc/subuid and /etc/subgid for an entry for your account, make sure the ranges are not duplicated or overlapping, and start a fresh login session after adding them. Re-run podman info to confirm the rootless configuration.

The published port is unavailable

Check whether another process or container already uses the host port:

podman ps
ss -ltn

Choose another host port, for example -p 8081:80, while leaving the container port at 80. Also check the host firewall and cloud security rules if clients connect from another machine.

The Quadlet service is missing

Confirm the file is in the correct directory, uses the .container suffix, and contains valid keys. Run systemctl --user daemon-reload after every change, then inspect:

systemctl --user status web.service
journalctl --user -u web.service

If the service must run without an interactive login, verify that cgroup v2 is available and that lingering is enabled for the owning account.

podman ps is empty but you expected a container

Check both scopes:

podman ps -a
sudo podman ps -a

A container created as rootless will not appear in root’s list, and vice versa. Also remember that podman ps excludes stopped containers; use -a to include them.

Operational and security practices

• Prefer rootless containers when the workload does not need host-level privileges.
• Use explicit image names and tags so a command does not silently select an unintended registry or tag.
• Review images and their documentation before running them, especially when they request host mounts, devices, or elevated capabilities.
• Keep application data in deliberately managed volumes and back them up independently of container removal.
• Use podman logs, podman inspect, and systemd journal output to diagnose failures rather than repeatedly recreating containers.
• Do not treat the root account inside a rootless container as host root.
• Keep the API socket disabled unless a client needs it, and protect the Unix socket with normal user or root permissions.
• Check the manuals installed with your package because command options and Quadlet keys can change between Podman releases.

A practical workflow for Ubuntu 24.04

1. Install the Ubuntu package with sudo apt-get update and sudo apt-get -y install podman.
2. Run podman --version and podman info to establish the installed build and host configuration.
3. Validate image pulls and runtime operation with podman run -it hello.
4. Use a named, published container such as the web example for learning lifecycle commands.
5. Set up subordinate UID and GID ranges before adopting rootless workloads that need user namespaces.
6. Choose rootless or rootful deliberately, remembering that each has separate images, containers, and systemd scope.
7. Move long-lived services to Quadlet files under the correct user or system directory, reload systemd, and manage the generated unit.
8. Start the API socket only for software that explicitly needs it.

Frequently Asked Questions

Do I need to start a Podman daemon before running a container?

No. Ordinary Podman commands such as podman run are daemonless. Start podman.socket only when a separate client needs the Docker-compatible API.

Why do podman ps and sudo podman ps show different containers?

They use different users and therefore different image and container stores. Rootless containers belong to your account; rootful containers belong to the host-root context.

Can rootless Podman use port 80?

It may be restricted by the host’s unprivileged-port policy. Use a higher host port such as 8080 for a straightforward rootless setup, or adjust host policy only after evaluating the security implications.

What should I use for a container that must start with systemd?

Use a Quadlet definition and let systemd generate and manage the service. Quadlet requires cgroup v2; place rootless files in ~/.config/containers/systemd/ and rootful administrator files commonly in /etc/containers/systemd/.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.