Preventing Rootless Podman from Filling Up My Home Directory with Container Logs

 Posted on 17 October 2026  |  3 minutes  |  532 words  |  Tom

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.

The good news is that you can keep those logs from turning your home into a data lake. Below are the most common, practical approaches, with trade‑offs and commands you can drop into your shell.

Log Rotation Basics

The simplest way to tame a runaway log is to rotate it. Systemd’s logrotate is the de‑facto standard on most distributions, and it works well for Podman’s file logs.

sudo nano /etc/logrotate.d/podman

Add:

/home/*/.config/containers/storage/overlay-containers/*/files/containers.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0600 $USER $USER
}
  • daily – rotate every day.
  • rotate 7 – keep a week’s worth of logs.
  • compress – gzip old logs.
  • create 0600 $USER $USER – ensure only the owner can read the new log.

After saving, test with:

sudo logrotate -d /etc/logrotate.d/podman

The -d flag shows what would happen without actually rotating. Once you’re satisfied, run:

sudo logrotate /etc/logrotate.d/podman

This keeps the logs in place but limits their size. It’s a low‑maintenance solution that works for most home‑lab setups.

Use Podman’s Built‑in Log Options

Podman supports Docker‑compatible log drivers, including journald, syslog, fluentd, and none. The default for rootless is journald, but if you’re using the file driver explicitly, you can change it:

podman run --log-driver=journald \
           --log-opt max-size=10m \
           --log-opt max-file=3 \
           myimage
  • max-size and max-file only apply to the json-file driver, but they’re harmless to specify with journald.
  • journald sends logs to the per‑user systemd journal, which you can limit with /etc/systemd/journald.conf:
[Journal]
SystemMaxUse=100M
SystemMaxFileSize=20M

Reload systemd:

systemctl --user daemon-reload
systemctl --user restart systemd-journald

Trade‑off: Journald logs are not stored in your home directory, so they don’t consume local disk space. However, they’re still accessible to the user, and if you’re running many containers, the journal can grow large if you don’t set limits.

Mount a Separate Log Directory

If you prefer to keep logs in a dedicated location (e.g., an SSD or a separate partition), bind‑mount a directory into the container’s log path:

mkdir -p ~/podman-logs
podman run -v ~/podman-logs:/var/log/myapp \
           myimage

Inside the container, configure your application to write to /var/log/myapp. The host will store the logs in ~/podman-logs, which you can then rotate or move elsewhere.

Caveat: Remember that the container’s internal path must match the application’s expectation. If you’re using a pre‑built image that writes to /var/log, you’ll need to override that with -v or modify the image.

systemd‑Based Log Rotation

For users who already run containers via systemd unit files (generated with podman generate systemd), you can leverage systemd’s StandardOutput and StandardError directives:

[Service]
ExecStart=/usr/bin/podman start mycontainer
StandardOutput=journal
StandardError=journal

This redirects container output to the user’s journal, which you can limit as shown earlier. If you prefer file logs, set:

StandardOutput=file:/home/$USER/podman-logs/%N.log
StandardError=
linux  open-source 

See also