podman snippet

podman

不同用户下执行 podman ps，只能查看当前用户的运行容器（即使是root用户，也不能查看其他普通用户启用的容器信息）

command

overview

1
2
3
4
5
# check disk usage
podman system df

# debug command 
podman --log-level=debug xxx

image

1
2
# load tar file to image
podman load -i <image-tar-file>

prune

1
2
3
4
5
6
7
8
# remove unused containers (stopped containers)
podman container prune

# delete dangling images (images not referenced by any container)
podman image prune

# comprehensive cleanup (all unused containers, images, pods, and optionally volumes)
podman system prune -a

best practices

change default data dir

  • rootful mode

    Default graphroot: /var/lib/containers/storage.

1
2
3
4
5
6
7
8
9
10
11
# check
podman info | grep 'graphRoot'

# Edit Podman’s Storage Configuration
sudo mkdir -p /etc/containers
sudo vim /etc/containers/storage.conf # root用户默认采用的配置

# edit storage.conf
[storage]
driver = "overlay"
graphroot = "/mnt/podman-root-data"

  • rootless mode

    Default graphroot: ~/.local/share/containers/storage.

1
2
3
4
5
6
7
8
9
10
11
12
# check
podman info | grep 'GraphRoot'

# Edit Podman’s Storage Configuration
mkdir -p ~/.config/containers
vim ~/.config/containers/storage.conf   # 普通用户默认采用的配置

# edit storge.conf
[storage]
driver = "overlay"
graphroot = "/mnt/podman-<userName>/data" # 普通用户和root用户的数据必须要区分开，不然会有目录权限操作的问题
runroot = "/mnt/podman-<userName>/run"

enable linger

Once linger is enabled, systemd will automatically start a background user manager for you at boot and will never shut it down when you close your SSH connection, keeping your containers alive indefinitely.

1
2
3
4
5
6
7
To run rootless Podman containers in the background permanently (even after you log out), you must instruct  systemd  to leave your user’s background processes alone.

# (Replace  dingofs  with your actual username if it differs from the user running the containers).
sudo loginctl enable-linger dingofs

# verify that linger is enabled by running, It should return  Linger=yes .
loginctl show-user dingofs | grep Linger

troubleshooting

potentially insufficient UIDs or GIDs available in user namespace

If the requested UID/GID still falls outside or Podman needs more mappings, you can edit /etc/subuid and /etc/subgid (as root) to increase the range

1
2
3
4
5
6
# Increase UID/GID Range (Optional):
sudo vim /etc/subuid  # dingofs:60000:131072
sudo vim /etc/subgid  # dingofs:60000:131072

# use current regular user, e.g. dingofs
podman system migrate

Error: creating events dirs: mkdir /run/user/1001: permission denied

1
2
3
4
5
# edit ~/.bashrc or ~/.zshrc
export XDG_RUNTIME_DIR=/run/user/$(id -u)

# available
source ~/.bashrc

error while loading shared libraries

when execute ‘podman run -it –entrypoint bash xxx’, occur ‘bash: error while loading shared libraries: /usr/lib64/libc.so.6: cannot apply additional memory protection after relocation: Permission denied’

1
sudo setenforce 0

ulimit: open files: cannot modify limit: Operation not permitted

use regular use could not operate ulimit command

  1. Set ulimit when starting the container

    1
    podman run -it --ulimit nofile=1048576:1048576 your_image

  2. Adjust host user limits (Edit /etc/security/limits.conf as root)

    1
    2
    your_username soft nofile 1048576
    your_username hard nofile 1048576

Error: unable to start container “xxx”: crun: setrlimit RLIMIT_NOFILE: Operation not permitted: OCI permission denied

Rootless Podman runs containers without root privileges and inherits the current user’s resource limits from the system . When a container’s RLIMIT_NOFILE (max open files) or RLIMIT_NPROC (max processes) configuration exceeds the user’s hard limits, crun (the OCI runtime) fails to apply them because non-root users cannot raise hard limits beyond system-defined values .

operate same with above 

1
2
3
# check
ulimit -Sn # soft open file
ulimit -Hn # hard open file

panic: runtime error: invalid memory address or nil pointer dereference

  • issue

    execute ‘podman system migrate’ occur issue

    1
    2
    3
    stopped 70802e06e7ae92ef5ac6cf2e90655988949f74799c088afe3589b2031e2371f7
    panic: runtime error: invalid memory address or nil pointer dereference
    [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x564e3393c85b]

  • solution

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    # check 
    echo $XDG_RUNTIME_DIR
    # If empty, set it:  export XDG_RUNTIME_DIR=/run/user/$(id -u)

    # Make sure user linger is enabled
    loginctl enable-linger $USER

    # Restart systemd user services
    systemctl --user daemon-reexec
    systemctl --user restart podman

    # Clean up rootless storage/socket
    rm -rf $XDG_RUNTIME_DIR/podman
    rm -rf $XDG_RUNTIME_DIR/libpod

    # If still stuck, consider resetting container storage:
    podman --log-level=debug system reset

podman ps issue: Falling back to –cgroup-manager=cgroupfs

  • warning

    1
    2
    3
    4
    WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available
    WARN[0000] For using systemd, you may need to log in using a user session
    WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 1001` (possibly as root)
    WARN[0000] Falling back to --cgroup-manager=cgroupfs

  • solution

    vim ~/.bashrc

    1
    2
    export XDG_RUNTIME_DIR=/run/user/$(id -u)
    export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u)/bus

    Switch Cgroup Manager to cgroupfs

    1
    2
    3
    4
    5
    mkdir -p ~/.config/containers
    cat >> ~/.config/containers/containers.conf << EOF
    [engine]
    cgroup_manager = "cgroupfs"
    EOF

Error: updating container state: unable to open database file: no such file or directory /run/user/xxx

  • analysis

    1
    Podman uses an internal database, typically SQLite or BoltDB depending on the version, to track container states, images, and storage paths. When operating in rootless mode, Podman stores temporary runtime data in volatile directories like  /run/user/$(id -u) . If the operating system clears these directories during a session logout or reboot, or if the database file itself becomes corrupted, Podman cannot locate the required state files and throws this error.

  • solution

    1
    2
    3
    4
    5
    6
    # optional check podman 所在磁盘无用数据，保证 podman 所在磁盘有可用空间
    sudo loginctl enable-linger $(id -un)
    systemctl --user daemon-reload

    # check
    ls -ld /run/user/xxx

machine restart: podman command: ERRO[0000] Refreshing container x: acquiring lock 1 for container x: file exists

  • analysis

    1
    2
    When your container was originally created, SELinux was enabled (or set to  Enforcing  /  Permissive ). Because of this, Podman recorded a specific SELinux security context in the container’s internal configuration so it could correctly label the shared memory mount (e.g.,  -o context="..." ).
    When you restarted your machine, SELinux was completely  Disabled . As a result, the Linux kernel no longer understands the SELinux  context  flag when Podman tries to mount the  tmpfs  directory. The kernel rejects the unrecognized option and returns the  invalid argument  (EINVAL) error.

  • solution

    Re-enable SELinux (Keeps original container intact)

    1
    2
    3
    4
    If you want to use the exact container without modifying it, you must re-enable SELinux so the kernel understands the mount flags again.
    1.	Open  /etc/selinux/config  and change  SELINUX=disabled  to  SELINUX=permissive  or  SELINUX=enforcing .
    2.	Reboot the machine.
    3.	Run  podman start xxx