{"id":169092,"date":"2026-06-18T19:25:51","date_gmt":"2026-06-18T16:25:51","guid":{"rendered":"https:\/\/computingforgeeks.com\/?p=169092"},"modified":"2026-06-18T19:25:51","modified_gmt":"2026-06-18T16:25:51","slug":"install-docker-podman-opensuse-leap","status":"publish","type":"post","link":"https:\/\/computingforgeeks.com\/install-docker-podman-opensuse-leap\/","title":{"rendered":"Install Docker and Podman on openSUSE Leap 16"},"content":{"rendered":"

openSUSE Leap 16 ships with Podman already installed and Docker one command away. The catch nobody warns you about is that both want to own the docker<\/code> command, and SELinux runs in enforcing mode by default, so a careless setup leaves you with either a broken docker<\/code> symlink or a container that cannot read its own volume.<\/p>\n\n

This guide installs Docker and Podman on openSUSE Leap 16 from the distribution repositories, runs real containers under each, and walks through the two things that actually bite on Leap: SELinux volume labels and how Docker punches straight through firewalld. By the end you will know which engine to reach for, have Compose running a multi-container stack, and be able to manage containers from Cockpit<\/a> in the browser.<\/p>\n\n

Ran the whole thing on a clean openSUSE Leap 16 box in June 2026, with SELinux left enforcing the entire time. Docker 29.4 and Podman 5.4, both working end to end.<\/em><\/p>\n\n

Docker or Podman on openSUSE Leap 16: which to install<\/h2>\n\n

Use Podman. It is the engine SUSE backs on Leap 16, it is already on the system, it runs rootless and daemonless, and it understands SELinux without any extra configuration. Reach for Docker when a specific tool expects the Docker daemon or its socket: a CI runner, a Compose file written against Docker behaviour, or a dev tool that talks to \/var\/run\/docker.sock<\/code>.<\/p>\n\n

You can run both engines on the same host and most people end up doing exactly that. The one hard rule is that only a single package can provide the docker<\/code> command, which is the first real decision this guide forces. Install the genuine Docker engine and you get the real docker<\/code>. Install the podman-docker<\/code> shim instead and docker<\/code> becomes an alias for Podman. You cannot have both.<\/p>\n\n

Prerequisites<\/h2>\n\n

You need a fresh openSUSE Leap 16 install<\/a>, a regular user with sudo<\/code> rights, and internet access to pull images. SELinux enforcing and an active firewalld are the Leap 16 defaults, and this guide keeps both on rather than switching them off.<\/p>\n\n

Sizing follows the workload, not the engine. Both Docker and Podman idle in tens of megabytes; the containers you run set the real RAM, CPU, and disk needs. The lab here is a 2 vCPU \/ 4 GB VM, which is fine for following along but is a floor, not a recommendation for a production container host. A box that runs a database plus a few services wants RAM sized to the working set and disk sized to your images plus volumes plus headroom.<\/p>\n\n

1. Update the system and confirm SELinux<\/h2>\n\n

Refresh the repositories and apply pending updates first, using the standard zypper commands<\/a>:<\/p>\n\n\n

sudo zypper refresh\nsudo zypper update<\/code><\/pre>\n\n\n
Confirm SELinux is enforcing. Leap 16’s switch to SELinux enforcing<\/a> by default is unusual for SUSE and shapes everything containers do with host files:<\/p>\n\n\n
getenforce<\/code><\/pre>\n\n\n
The mode should come back as enforcing:<\/p>\n\n\n
Enforcing<\/code><\/pre>\n\n\n
The policy that lets containers work under enforcing mode lives in the container-selinux<\/code> package, which the container engines pull in as a dependency. You do not install it by hand, but it is the reason the volume-label step later actually has an effect.<\/p>\n\n
2. Install and test Podman<\/h2>\n\n
Podman is part of the default Leap 16 install. On a minimal or server pattern it may be missing, so install it explicitly if needed:<\/p>\n\n\n
sudo zypper install podman<\/code><\/pre>\n\n\n
Check the version to confirm it is present:<\/p>\n\n\n
podman --version<\/code><\/pre>\n\n\n
Now run a container as your normal user, with no sudo<\/code> and no daemon:<\/p>\n\n\n
podman run --rm hello-world<\/code><\/pre>\n\n\n
Podman resolves the short name, pulls the image, and prints its greeting:<\/p>\n\n\n
Trying to pull quay.io\/podman\/hello:latest...\n!... Hello Podman World ...!<\/code><\/pre>\n\n\n
That container ran rootless. Podman 5 on Leap uses the netavark network stack and pasta for rootless networking, with image storage under your home directory. Confirm it:<\/p>\n\n\n
podman info | grep -iE \"rootless|networkBackend|graphRoot\"<\/code><\/pre>\n\n\n
The output names the backend and shows that the store lives in your home, not in a system path:<\/p>\n\n\n
  networkBackend: netavark\n  rootlessNetworkCmd: pasta\n    rootless: true\n  graphRoot: \/home\/geek\/.local\/share\/containers\/storage<\/code><\/pre>\n\n\n
This rootless-by-default behaviour is Podman’s headline advantage on Leap. The full command set is documented in the official Podman documentation<\/a>.<\/p>\n\n
3. Install and test Docker<\/h2>\n\n
Docker is not installed by default. Pull the engine, the Compose plugin, and buildx from the openSUSE repository. Note that Docker’s own download.docker.com repository has no openSUSE Leap build, so the distribution package is the correct source here, not a third-party repo:<\/p>\n\n\n
sudo zypper install docker docker-compose docker-buildx<\/code><\/pre>\n\n\n
Check the engine and Compose versions:<\/p>\n\n\n
docker --version\ndocker compose version<\/code><\/pre>\n\n\n
Both report cleanly:<\/p>\n\n\n
Docker version 29.4.0-ce, build daa0cb7f23\nDocker Compose version 2.33.1<\/code><\/pre>\n\n\n
One detail trips people up: the docker-compose<\/code> package on Leap installs the v2 plugin you call as docker compose<\/code> (a space, not a hyphen). There is no standalone docker-compose<\/code> binary, so old scripts that call the hyphenated command will fail until you update them.<\/p>\n\n
Unlike Podman, Docker needs a running daemon. Enable and start it:<\/p>\n\n\n
sudo systemctl enable --now docker<\/code><\/pre>\n\n\n
Confirm the service is active:<\/p>\n\n\n
systemctl is-active docker<\/code><\/pre>\n\n\n
It should report running:<\/p>\n\n\n
active<\/code><\/pre>\n\n\n
To run docker<\/code> without sudo<\/code>, add your user to the docker<\/code> group:<\/p>\n\n\n
sudo usermod -aG docker $USER<\/code><\/pre>\n\n\n
The gotcha here is that group membership only applies to new login sessions. Pick up the new group in your current shell with newgrp docker<\/code>, or log out and back in, then run a container:<\/p>\n\n\n
docker run --rm hello-world<\/code><\/pre>\n\n\n
Docker pulls the image and prints the familiar confirmation, which means both engines are now live on the same host. Adding the daemon to the picture is the practical difference from Podman; the rest of the workflow is documented in the Docker Engine documentation<\/a>.<\/p>\n\n\n
\"docker<\/figure>\n\n\n
Both engines now respond on the same machine. The next question is what happens to the docker<\/code> command itself when you want Podman to answer to it too.<\/p>\n\n
4. Run both engines side by side<\/h2>\n\n
With both installed, podman<\/code> drives Podman and docker<\/code> drives Docker. They keep separate image stores and separate networks, so they coexist without stepping on each other. The only clash appears if you also want Podman to answer to the docker<\/code> command through the podman-docker<\/code> package. Try it on a host that already has the real Docker:<\/p>\n\n\n
sudo zypper install podman-docker<\/code><\/pre>\n\n\n
zypper refuses, because both packages provide \/usr\/bin\/docker<\/code>:<\/p>\n\n\n
Problem: 1: the to be installed podman-docker-5.4.2 conflicts with 'docker'\n provided by the installed docker-29.4.0_ce\n Solution 1: deinstallation of docker-29.4.0_ce<\/code><\/pre>\n\n\n
So decide up front. If you want the genuine Docker engine, keep the docker<\/code> package and skip podman-docker<\/code>. If you would rather run only Podman but keep typing docker<\/code> out of habit, do not install the Docker engine at all; install podman-docker<\/code> instead and it drops a thin \/usr\/bin\/docker<\/code> wrapper that forwards every command to Podman.<\/p>\n\n
5. SELinux and container volumes<\/h2>\n\n
This is the section that costs people an afternoon. Leap 16 runs SELinux in enforcing mode, so a host directory you bind-mount into a container carries its home-directory label, and the container is not allowed to read it. The fix is one character, but only if you know it exists.<\/p>\n\n
Create a file and look at its SELinux label:<\/p>\n\n\n
echo \"secret host page\" > ~\/denied.html\nls -Z ~\/denied.html<\/code><\/pre>\n\n\n
The label is the generic home-directory type:<\/p>\n\n\n
unconfined_u:object_r:user_home_t:s0 \/home\/geek\/denied.html<\/code><\/pre>\n\n\n
Mount it into a container with no relabel flag and the read is blocked:<\/p>\n\n\n
podman run --rm -v ~\/denied.html:\/data\/index.html:ro alpine cat \/data\/index.html<\/code><\/pre>\n\n\n
SELinux denies it, and the error is the one you will see in a hundred forum posts:<\/p>\n\n\n
cat: can't open '\/data\/index.html': Permission denied<\/code><\/pre>\n\n\n
Add the :Z<\/code> suffix to the volume and the engine relabels the file with a container-private type so the container can read it:<\/p>\n\n\n
podman run --rm -v ~\/denied.html:\/data\/index.html:ro,Z alpine cat \/data\/index.html<\/code><\/pre>\n\n\n
This time the content comes through:<\/p>\n\n\n
secret host page<\/code><\/pre>\n\n\n
Use lowercase :z<\/code> when several containers share the same volume, and uppercase :Z<\/code> when one container owns it exclusively. The difference matters: :Z<\/code> stamps a private label that other containers cannot use. The same rule applies to Docker, because its daemon on Leap also runs with SELinux enabled, so reach for :z<\/code> or :Z<\/code> on every host bind-mount rather than disabling SELinux.<\/p>\n\n\n
\"Podman<\/figure>\n\n\n
Volume labels are one of two Leap defaults that change how containers behave. The other one is the firewall.<\/p>\n\n
6. Published ports and firewalld<\/h2>\n\n
firewalld is active by default on Leap 16, but Docker does not ask it for permission. Publish a port and the container is reachable immediately:<\/p>\n\n\n
docker run -d --name web -p 8080:80 nginx:alpine\ncurl -s -o \/dev\/null -w \"HTTP %{http_code}\\n\" http:\/\/localhost:8080\/<\/code><\/pre>\n\n\n
The web server answers on the published port:<\/p>\n\n\n
HTTP 200<\/code><\/pre>\n\n\n
That works because Docker installs its own nftables DOCKER<\/code> chain and a permissive docker<\/code> firewalld zone, so container traffic is diverted before firewalld’s public-zone rules ever see it. You can see the chain it manages:<\/p>\n\n\n
sudo nft list chain ip filter DOCKER<\/code><\/pre>\n\n\n
Docker’s accept and drop rules sit in their own chain:<\/p>\n\n\n
table ip filter {\n\tchain DOCKER {\n\t\tip daddr 172.17.0.2 iifname != \"docker0\" oifname \"docker0\" tcp dport 80 accept\n\t\tiifname != \"docker0\" oifname \"docker0\" drop\n\t}\n}<\/code><\/pre>\n\n\n
The practical consequence: a published Docker port is exposed to anything that can reach the host, even though firewalld’s public zone looks locked down. Bind sensitive containers to a specific interface with -p 127.0.0.1:8080:80<\/code>, or put a reverse proxy in front, rather than trusting firewalld to gate the port. Rootless Podman behaves differently here, since it binds published ports as your user through pasta and never touches the system firewall rules. Clean up the test container when you are done:<\/p>\n\n\n
docker rm -f web<\/code><\/pre>\n\n\n
Single containers are the building block. Compose stitches several of them into one definition you start and stop together.<\/p>\n\n
7. Run a multi-container app with Compose<\/h2>\n\n
Compose ties several containers into one definition. Create a project directory and open a Compose file:<\/p>\n\n\n
mkdir ~\/composeapp && cd ~\/composeapp\nvim compose.yaml<\/code><\/pre>\n\n\n
Define a web server and a Redis cache:<\/p>\n\n\n
services:\n  web:\n    image: nginx:alpine\n    ports:\n      - \"8080:80\"\n  cache:\n    image: redis:alpine<\/code><\/pre>\n\n\n
Bring the stack up in the background:<\/p>\n\n\n
docker compose up -d<\/code><\/pre>\n\n\n
Both services start and Compose creates a network for them:<\/p>\n\n\n
 Container composeapp-cache-1  Started\n Container composeapp-web-1  Started<\/code><\/pre>\n\n\n
Check what is running:<\/p>\n\n\n
docker compose ps<\/code><\/pre>\n\n\n
Both containers report up, with the web port published:<\/p>\n\n\n
NAME                 IMAGE          STATUS         PORTS\ncomposeapp-cache-1   redis:alpine   Up             6379\/tcp\ncomposeapp-web-1     nginx:alpine   Up             0.0.0.0:8080->80\/tcp<\/code><\/pre>\n\n\n
Podman can borrow the same plugin. Running podman compose<\/code> on a host that has the Docker Compose plugin installed delegates to it, printing a note that it is using the external provider, so your Compose files work under either engine. Tear the stack down when you are finished:<\/p>\n\n\n
docker compose down<\/code><\/pre>\n\n\n
Everything so far ran in a terminal. Leap 16 also gives you a browser view of your containers if you want one.<\/p>\n\n
8. Manage containers from Cockpit<\/h2>\n\n
If you set up the Cockpit web console as the YaST replacement, the cockpit-podman<\/code> add-on gives you a container view in the browser without leaving the dashboard. Install it and enable the Podman system socket it talks to:<\/p>\n\n\n
sudo zypper install cockpit-podman\nsudo systemctl enable --now podman.socket<\/code><\/pre>\n\n\n
Reload Cockpit and a Podman containers entry appears in the sidebar, listing your images and containers with live CPU and memory, plus buttons to start, stop, and create. It is a comfortable way to watch a host at a glance, and it pairs naturally with the rest of the Cockpit administration workflow<\/a> on Leap 16.<\/p>\n\n\n
\"Cockpit<\/figure>\n\n\n
That covers the everyday workflow. A few errors come up often enough on Leap to call out directly.<\/p>\n\n
Troubleshooting Docker and Podman on Leap 16<\/h2>\n\n
These are the three errors that actually came up while testing, with the fix for each.<\/p>\n\n
permission denied while trying to connect to the Docker daemon socket<\/h3>\n\n
You added yourself to the docker<\/code> group but kept using the same shell. Group changes only take effect in a new login session. Run newgrp docker<\/code> in the current terminal, or log out and back in, then retry the command.<\/p>\n\n
cat: can’t open … Permission denied on a mounted file<\/h3>\n\n
This is SELinux, not a file-permission problem. The host path you bind-mounted still carries its original label. Add :z<\/code> (shared) or :Z<\/code> (private) to the -v<\/code> flag so the engine relabels it for container access, as shown in the SELinux section above.<\/p>\n\n
podman-docker conflicts with ‘docker’<\/h3>\n\n
Both packages try to own \/usr\/bin\/docker<\/code>, so they cannot be installed together. Decide which command you want: keep the docker<\/code> package for the real engine, or remove it and install podman-docker<\/code> to make docker<\/code> an alias for Podman.<\/p>\n\n
One last note on rootless. Podman runs rootless with no extra steps, which is most of the reason to prefer it on Leap. Docker can run rootless too, through dockerd-rootless-setuptool.sh install<\/code> from the docker-rootless-extras<\/code> package, but it is a heavier setup involving a per-user daemon and lingering sessions. If running without root is the goal, Podman gets you there for free, and you can promote a tested container to a systemd-managed service<\/a> once it earns a permanent home.<\/p>\n","protected":false},"excerpt":{"rendered":"
openSUSE Leap 16 ships with Podman already installed and Docker one command away. The catch nobody warns you about is that both want to own the docker command, and SELinux runs in enforcing mode by default, so a careless setup leaves you with either a broken docker symlink or a container that cannot read its … Read more<\/a><\/p>\n","protected":false},"author":7,"featured_media":169093,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[316,299,47,50],"tags":[218,217,9986,4449],"cfg_series":[39887],"class_list":["post-169092","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-containers","category-how-to","category-linux","category-linux-tutorials","tag-containers","tag-docker","tag-opensuse","tag-podman","cfg_series-opensuse-leap-16"],"_links":{"self":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/169092","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/comments?post=169092"}],"version-history":[{"count":1,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/169092\/revisions"}],"predecessor-version":[{"id":169098,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/169092\/revisions\/169098"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/media\/169093"}],"wp:attachment":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/media?parent=169092"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/categories?post=169092"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/tags?post=169092"},{"taxonomy":"cfg_series","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/cfg_series?post=169092"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}