Linux Café

Ubuntu 24.04 ships with a fully‑featured Podman package that works out of the box.
Rootless mode lets a normal user spin up containers without any privileged operations, which is a great fit for a home lab or a small self‑hosted service.
Below is a step‑by‑step guide to build a minimal Nginx image, run it rootlessly, and keep the whole thing under tight, sane defaults.

Prerequisites

• Ubuntu 24.04 (LTS) installed on a machine or VM.
• A non‑root user with sudo privileges (the example assumes alice).
• Basic knowledge of the shell, sudo, and systemd.

# Verify the kernel version – user namespaces require 5.8+ (Ubuntu 24.04 uses 6.6)
uname -r
# Install Podman if it isn’t already
sudo apt update
sudo apt install -y podman

Enable rootless mode

Podman automatically falls back to rootless when run as a normal user, but you should confirm that the user‑namespace mapping is in place:

The Problem

Running a rootless Podman container on a home‑lab server is great for isolation, but the logs it spits out can quietly eat up disk space. I once had a simple nginx container that, after a few days, filled a 20 GB SSD with log files. The container was running as my normal user, so I couldn’t just rm -rf /var/lib/containers/... without risking a permission error. The real issue was that Podman, by default, writes container stdout/stderr to files under /var/lib/containers/storage/overlay-containers/.../files/var/log/ and those files never rotate.

Recover a single file from a damaged Borg archive

When a Borg repository gets corrupted, the instinct is to dump the whole thing back. That’s usually overkill if you just need one config file. Borg actually gives you a fine‑grained extraction tool that can pull a single file even from a partially broken archive.

1. Verify the repository

borg check /srv/backups/myrepo

borg check will surface any integrity problems. If you see corruption, you can try to fix it:

Why Rootless Podman Can Bloat Your Home

When I first started juggling a handful of lightweight services in Podman from a non‑root account, my $HOME started filling up faster than my Git repos. The culprit? The per‑container log files that Podman writes under

$HOME/.config/containers/storage/overlay-containers/*/files/containers.log

If a container misbehaves or just beeps a lot, those logs can grow to gigabytes. Rootless Podman defaults to the file log driver when you explicitly request one, so the logs stay in your home directory and can fill up the disk before you notice anything.

Running a nightly backup from a home NAS to a desktop is a common task, but the copy can still hog the machine’s resources and make the UI feel sluggish.
The trick is to let the backup run with low CPU and I/O priority so the desktop stays responsive. Two simple tools—nice and ionice—are all you need.

Why the problem matters

When a rsync or tar job copies gigabytes of data, the kernel’s scheduler keeps the process in the foreground class. Even if you’re not actively using the machine, the backup can consume CPU cycles and saturate the disk queue. On a laptop or a desktop with a single NVMe drive, this shows up as a frozen terminal, delayed window redraws, or a sluggish browser.

I was running a hobbyist homelab on a Raspberry Pi 4 with 32 GB of eMMC storage. The Pi was a low‑cost, low‑power server that hosted a few services: a personal web server, a GitLab runner, and a Docker build farm for CI pipelines. The build farm was a simple script that pulled the latest code, built a Docker image, and pushed it to a registry. Everything worked until the disk filled up during a large multi‑stage build.

When the disk is almost full

I’ve run a handful of home‑servers for years, and the first thing that usually trips you up is a suddenly full disk.
Caches from apt, Docker, Flatpak, and the like can balloon without you noticing.
A quick, automated cleanup that only kicks in when the root filesystem is >90 % used keeps the system sane without you having to remember to run a script every week.

I’m ready to help, but I need the article text you’d like me to rewrite. Could you paste it in here?

On a small home‑lab server or a single‑user laptop, the root filesystem is often the first place that runs out of space. I ran into this on a 2025‑era Raspberry Pi running Ubuntu 24.04 LTS: the systemd journal kept growing until the root partition hit 95 % and the machine refused to boot. The fix was surprisingly simple once you understand how systemd‑journald works and how to steer its output away from the root filesystem.

When Clonezilla says root=UUID not found

Cloning a bootable SSD with Clonezilla is usually painless, but the new machine can stall at the kernel prompt with:

root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx not found

The kernel can’t locate the root filesystem because the UUIDs in the boot configuration still point to the original disk. The fix is a handful of targeted edits and rebuilds.

1. Verify the new UUIDs

Boot from a live USB, open a terminal and list the block devices: