通过podman加载的容器镜像重启后丢失，如何持久化保存？

问题描述 #

我通过Podman安装容器镜像，执行命令podman pull docker-archive:myimage-amd64.tar.gz成功，podman images也能列出该镜像：

localhost/myimage                                      amd64       090ab0ddc80a  2 years ago    597 MB

但重启系统后，该容器镜像不再可用，必须重新加载，执行podman images也无法看到它。请问如何持久化保存已安装的镜像？

以下是我的storage.conf文件内容：

This file is is the configuration file for all tools
# that use the containers/storage library.
# See man 5 containers-storage.conf for more information
# The "container storage" table contains all of the server options.
[storage]
 
# Default Storage Driver
driver = "overlay"
 
# Temporary storage location
runroot = "/var/run/containers/storage"
 
# Primary Read/Write location of container storage
graphroot = "/var/lib/containers/storage"
 
[storage.options]
# Storage options to be passed to underlying storage drivers
 
# AdditionalImageStores is used to pass paths to additional Read/Only image stores
# Must be comma separated list.
additionalimagestores = [
]
 
# Size is used to set a maximum size of the container image.  Only supported by
# certain container storage drivers.
size = ""
 
# Path to an helper program to use for mounting the file system instead of mounting it
# directly.
#mount_program = "/usr/bin/fuse-overlayfs"
 
# OverrideKernelCheck tells the driver to ignore kernel checks based on kernel version
#override_kernel_check = "true"
 
# mountopt specifies comma separated list of extra mount options
mountopt = "nodev"
 
# Remap-UIDs/GIDs is the mapping from UIDs/GIDs as they should appear inside of
# a container, to UIDs/GIDs as they should appear outside of the container, and
# the length of the range of UIDs/GIDs.  Additional mapped sets can be listed
# and will be heeded by libraries, but there are limits to the number of
# mappings which the kernel will allow when you later attempt to run a
# container.
#
# remap-uids = 0:1668442479:65536
# remap-gids = 0:1668442479:65536
 
# Remap-User/Group is a name which can be used to look up one or more UID/GID
# ranges in the /etc/subuid or /etc/subgid file.  Mappings are set up starting
# with an in-container ID of 0 and the a host-level ID taken from the lowest
# range that matches the specified name, and using the length of that range.
# Additional ranges are then assigned, using the ranges which specify the
# lowest host-level IDs first, to the lowest not-yet-mapped container-level ID,
# until all of the entries have been used for maps.
#
# remap-user = "storage"
# remap-group = "storage"
 
[storage.options.thinpool]
# Storage Options for thinpool
 
# autoextend_percent determines the amount by which pool needs to be
# grown. This is specified in terms of % of pool size. So a value of 20 means
# that when threshold is hit, pool will be grown by 20% of existing
# pool size.
# autoextend_percent = "20"
 
# autoextend_threshold determines the pool extension threshold in terms
# of percentage of pool size. For example, if threshold is 60, that means when
# pool is 60% full, threshold has been hit.
# autoextend_threshold = "80"
 
# basesize specifies the size to use when creating the base device, which
# limits the size of images and containers.
# basesize = "10G"
 
# blocksize specifies a custom blocksize to use for the thin pool.
# blocksize="64k"
 
# directlvm_device specifies a custom block storage device to use for the
# thin pool. Required if you setup devicemapper.
# directlvm_device = ""
 
# directlvm_device_force wipes device even if device already has a filesystem.
# directlvm_device_force = "True"
 
# fs specifies the filesystem type to use for the base device.
# fs="xfs"
 
# log_level sets the log level of devicemapper.
# 0: LogLevelSuppress 0 (Default)
# 2: LogLevelFatal
# 3: LogLevelErr
# 4: LogLevelWarn
# 5: LogLevelNotice
# 6: LogLevelInfo
# 7: LogLevelDebug
# log_level = "7"
 
# min_free_space specifies the min free space percent in a thin pool require for
# new device creation to succeed. Valid values are from 0% - 99%.
# Value 0% disables
# min_free_space = "10%"
 
# mkfsarg specifies extra mkfs arguments to be used when creating the base.
# device.
# mkfsarg = ""
 
# use_deferred_removal marks devicemapper block device for deferred removal.
# If the thinpool is in use when the driver attempts to remove it, the driver 
# tells the kernel to remove it as soon as possible. Note this does not free
# up the disk space, use deferred deletion to fully remove the thinpool.
# use_deferred_removal = "True"
 
# use_deferred_deletion marks thinpool device for deferred deletion.
# If the device is busy when the driver attempts to delete it, the driver
# will attempt to delete device every 30 seconds until successful.
# If the program using the driver exits, the driver will continue attempting
# to cleanup the next time the driver is used. Deferred deletion permanently
# deletes the device and all data stored in device will be lost.
# use_deferred_deletion = "True"
 
# xfs_nospace_max_retries specifies the maximum number of retries XFS should
# attempt to complete IO when ENOSPC (no space) error is returned by
# underlying storage device.
# xfs_nospace_max_retries = "0"
 
# If specified, use OSTree to deduplicate files with the overlay backend
#ostree_repo = ""
 
# Set to skip a PRIVATE bind mount on the storage home directory.  Only supported by
# certain container storage drivers
#skip_mount_home

解决方法 #

1. 检查存储目录的挂载类型

Podman默认把镜像存在/var/lib/containers/storage，如果这个目录挂载在临时文件系统（比如tmpfs）上，重启就会清空。执行以下命令验证：

df -h /var/lib/containers/storage

如果输出中Type列是tmpfs，需要修改/etc/fstab或系统挂载配置，把该目录挂载到持久化磁盘分区。

2. 确认操作用户一致性

Podman会区分用户存储：

• root用户拉取的镜像存在/var/lib/containers/storage
• 普通用户拉取的镜像存在~/.local/share/containers/storage

重启后必须用同一个用户执行podman images才能看到镜像，切换用户会导致无法查询到。

3. 排查自动清理机制

检查系统是否有定时任务或服务在重启时清理容器存储目录：

ls -la /etc/cron.daily/ /etc/cron.hourly/
systemctl list-unit-files | grep clean

如果发现相关清理脚本或服务，修改配置排除/var/lib/containers/storage目录。

4. 重置Podman存储（可选，会清空现有数据）

如果以上步骤都无效，尝试重置Podman存储后重新拉取镜像：

podman system reset

注意：该命令会删除所有现有镜像、容器、卷等数据，执行前请备份重要内容。

内容的提问来源于stack exchange，提问作者sbunny