Clouds blog

Category: Podman

  • Podman on Windows: Permission errors on mounted volumes

    Podman on Windows: Permission errors on mounted volumes

    Running Podman on Windows is mostly smooth—until you mount a volume and a database tries to touch filesystem permissions. That’s where things broke for me during a MariaDB upgrade via container (https://hub.docker.com/_/mariadb).

    The Problem

    I was running MariaDB via a Podman Compose file with a mounted volume. On startup, MariaDB attempted an auto upgrade and failed while updating system tables. The container logs were full of permission errors like:

    ERROR 32 (HY000): Can't change permissions of the file './sys/version.frm-' (Errcode: 1 "Operation not permitted")

    This repeated across multiple files under ./sys/*. In short: MariaDB couldn’t chmod files on the mounted volume.

    Why This Happens on Windows

    Podman on Windows can runs rootless containers inside a WSL2. When you mount a Windows directory into a container, UID/GID mapping can become a mess. Without explicit mapping, the container’s user may not have permission to change ownership or modes on files backed by the Windows filesystem.

    MariaDB’s upgrade process expects to change permissions. If it can’t, the upgrade aborts, but can be repeated.

    The Fix: Explicit UID Mapping in Compose

    The solution was to define a UID map for Podman in the Compose file:

        volumes:
          - "D:/www/blog/db:/var/lib/mysql:Z"
    x-podman:
    uidmaps:
    - 65534:65534:1

    After adding this and restarting the stack, MariaDB upgraded successfully on its own—no manual intervention, no data loss.

    What This Does

    • 65534 maps the container user to the “nobody” UID on the host side.
    • This mapping aligns permissions in a way Podman on Windows can actually enforce.
    • MariaDB can now modify file permissions during initialization and upgrades.

    Result

    • MariaDB container starts cleanly
    • Upgrade completes automatically
    • No more Operation not permitted errors
    • Same data directory, same volume, no hacks

    Takeaway

    If you’re using Podman on Windows with mounted volumes and hit unexplained permission errors, assume UID/GID mapping is the culprit. Docker often hides this problem. Podman does not.

    Be explicit. Compose supports it. Use it.

    Related links:
    – https://github.com/containers/podman/issues/2898
    – https://stackoverflow.com/questions/75817076/no-matter-what-i-do-podman-is-mounting-volumes-as-root