Running Home Assistant in a rootless Podman container feels like a no‑frills, privilege‑minimal setup that sits comfortably in a homelab. The real pain point is making sure the image and its data stick around after a reboot when you don’t want to hit a Docker‑compatible registry. The trick is to treat a small part of the local filesystem as a “registry” and let Podman pull from it every time the system boots.
[Read More]When Docker runs on a modern Linux distro, every container start, stop, or health‑check event is logged by the Docker daemon (dockerd). Those logs are forwarded to systemd‑journal, which is great for auditability but can quickly flood the journal with repetitive, low‑value messages. On a busy host a single day of activity can generate several megabytes of journal data, making it hard to spot real issues and bumping disk usage.
Running containers as a non‑root user is a solid first line of defense, but it’s not a silver bullet. A mis‑configured image, a vulnerable app, or a simple oversight can still let a container touch /etc, /var, or even your own home directory. This post walks through the hardening steps that keep file writes strictly inside a rootless runtime’s writable layer.
Rootless mode is all about user namespaces. The container’s root (uid 0) gets mapped to a non‑root UID on the host, and the kernel enforces that the process can only see files that belong to that UID. The catch is that the mapping is per‑process, not per‑filesystem. If a container mounts a host directory or a volume, the process inside can write to it unless the mount options explicitly deny it.
Rootless Podman runs containers as an unprivileged user, so a bind‑mount that works for root often fails with “Permission denied.” That error is usually a mismatch between the host directory’s ownership/permissions and the container’s user namespace. Below is a quick checklist that gets the mounts working again while keeping the isolation tight.
| Cause | Why it happens | Typical symptom |
|---|---|---|
| File ownership | The host directory is owned by root or another UID that the container’s user can’t read/write. | mount: permission denied or open /data/file: Permission denied inside the container. |
| SELinux/AppArmor context | The host directory’s security context blocks the container’s process. | Same “Permission denied” even when file permissions look right. |
| User‑namespace mapping | Podman maps container UID 0 to a non‑zero host UID. If the host directory is owned by root, the mapped UID has no rights. | Error appears only when --userns=keep-id is omitted. |
| Mount options | Using :Z/:z incorrectly or omitting them when SELinux is enabled. |
SELinux denies the mount, causing the error. |
Match ownership
[Read More]I’ve seen container logging become a major headache for many of us managing containerized applications. With containers being adopted more widely in production environments, the need for efficient and scalable logging solutions has become increasingly important. Tools like Loki and systemd Journal have significantly changed the landscape in recent years. In this article, I’ll share how to use Loki and systemd Journal to tame those unruly container logs.
[Read More]I’ve seen this go wrong when managing Docker on a small Linux server: volumes can become a challenge. Docker volumes are directories that are shared between the host system and containers, allowing for persistent data storage. If not properly managed, they can lead to disk space issues and security risks. The real trick is to stay on top of volume management to avoid these problems.
To create a new volume, you can use the docker volume command. For example, to create a new volume named my-volume, you can use the following command:
I’ve seen containerized applications generate a staggering amount of log data, making it a nightmare to manage and analyze. Luckily, tools like jq and systemd-journald can help tame the container log mess. In this article, I’ll focus on practical examples and commands to get you started with container log management.
Container logs are usually stored in JSON format, which makes them easy to parse and analyze using jq. The real trick is knowing how to extract the relevant information. For example, you can use the following command to extract the log level and message from a container log:
When I’m working with containers, I’ve seen this go wrong when an application consumes all available system resources, leading to performance issues and even crashes. Luckily, the Linux kernel and container runtimes like Podman have made significant strides in providing better resource management tools. As of 2026, we have even more robust methods to tame these resource-intensive containers using cgroups and Podman.
cgroups, or control groups, are a Linux kernel feature that allows system administrators to allocate and manage resources such as CPU, memory, and I/O devices among different groups of processes. I usually start with a simple example to understand how cgroups work. cgroups provide a hierarchical structure, enabling administrators to create and manage resource limits for various applications and services. By utilizing cgroups, you can ensure that resource-hungry containers do not overwhelm the system, causing performance degradation or downtime.
[Read More]Managing containers can be a challenge, especially when it comes to persistent volumes. I’ve seen this go wrong when teams don’t plan ahead, leading to data loss or security issues. As of 2026, containerization is a staple in the Linux ecosystem, with tools like Podman and systemd making it easier to manage and orchestrate containers.
Podman is a daemonless container engine that simplifies container and volume management. To create a persistent volume, use the podman volume command:
I’ve seen this go wrong when working with containers - resource-intensive applications can quickly consume system resources, leading to performance issues and potential security risks. The real trick is to effectively manage and limit resources for containers. In recent years, the Linux community has made significant strides in container management, particularly with the development of Podman, a daemonless container engine. As I’ve worked with Podman, I’ve come to appreciate its CPU limiting features and how they can be combined with cgroups to create a robust resource management system.
[Read More]