Podman
Summary
Podman is the raw container engine used for direct container work on Fedora Atomic. Use it when you want to pull images, create containers, expose ports, mount directories, inspect state, and manage workloads that behave more like services than temporary development shells.
Why this matters
- Podman is the correct layer for containerised services and lower-level container workflows
- understanding Podman helps you troubleshoot what happens underneath Toolbox and other container-based tools
- if you use the wrong container model, you can expose the wrong files, map the wrong ports, or create containers that are hard to reason about later
Environment / Scope
| Item | Value |
|---|---|
| Platform | Fedora SWAY Atomic |
| Main tool | podman |
| Best use for this note | beginner to junior practical workflow |
| Safe to test? | yes, in a lab |
| Related area | containers / homelab / service testing |
Key concepts
- Image - a reusable template used to create containers
- Container - a running or stopped instance created from an image
- Mount / volume - a host path made available inside the container
- Port mapping - exposing a port from the container to the host
- Rootless workflow - running containers as your normal user instead of defaulting to root-level habits
When to use Podman vs Toolbox
| Use case | Better choice | Why |
|---|---|---|
| You need direct container control | Podman | you manage the image, mounts, ports, and lifecycle yourself |
| You want a dev shell with familiar tooling | Toolbox | it is more convenient for day-to-day development work |
| You want to run a service or test a containerised app | Podman | that is exactly what the raw engine is for |
Steps / Workflow
Workflow 1: make an isolated container
- Pull the image.
- Verify that the image exists locally.
- Create the container without starting it yet.
- Check that the container exists.
- Start it interactively.
podman pull ubuntu:24.04
podman images
podman create --name ubuntu-24 ubuntu:24.04 bash
podman ps -a
podman start -ai ubuntu-24Workflow 2: make a container with access to your home directory
Use this only when you intentionally want the container to work against files in your user environment.
podman create --name ubuntu-24 --userns=keep-id -v $HOME:$HOME -w $HOME ubuntu:24.04 bash
podman start -ai ubuntu-24Before using a home-directory mount
This is no longer an isolated environment. The container can read and modify files in the mounted path, so use this deliberately and only when that behaviour is actually wanted.
Commands / Examples
Basic commands
podman pull ubuntu:24.04
podman images
podman ps
podman ps -a
podman logs ubuntu-24
podman rm ubuntu-24Important flags from the workflow
| Part | Meaning |
|---|---|
--name ubuntu-24 | gives the container a readable name |
-a | attach to the container output |
-i | keep input open so you can interact with it |
--userns=keep-id | keep your user identity mapping inside the container |
-v $HOME:$HOME | mount your home directory from host to container |
-w $HOME | set the working directory inside the container |
Example output
CONTAINER ID IMAGE COMMAND STATUS NAMES
abc123def456 ubuntu:24.04 bash Exited (0) 10 seconds ago ubuntu-24Verification
| Check | Expected result |
|---|---|
| Image exists | visible in podman images |
| Container exists | visible in podman ps -a |
| Interactive start works | container shell opens without errors |
| Mounted path behaves as expected | expected files are visible and writable only when intended |
Verification commands:
podman images
podman ps -a
podman inspect ubuntu-24Pitfalls / Troubleshooting
| Problem | Likely cause | What to check |
|---|---|---|
| Container is missing | image not pulled or container removed | podman images, podman ps -a |
| Container starts then exits | command finishes immediately | startup command, container logs |
| Files get modified unexpectedly | host path was mounted intentionally or by mistake | -v usage, target path |
| Wrong ownership on mounted files | user mapping mismatch | --userns=keep-id, current user |
Watch out
The most important difference between the two workflows is isolation. A container with a host mount is not just a safe disposable shell anymore.
Key takeaways
- Podman is the right tool when you need direct control over containers
createplusstarthelps you see each stage of container lifecycle more clearly than jumping straight into a one-liner- mounting
$HOMEis useful, but it changes the risk profile and should not be treated like an isolated container