rootless模式Podman启动ubi8等镜像报tar处理操作不支持错误

• 镜像启动表现不一致的核心差异来自镜像层结构：alpine、ubuntu基础镜像的分层打包过程中没有使用overlayfs的不透明目录标记，解压写入存储时不需要写入特殊扩展属性；而ubi8、grafana/grafana-oss的镜像层存在全目录覆盖下层同名目录的设计，解压时需要为对应目录写入trusted.overlay.opaque扩展属性标记，触发了底层文件系统的能力限制。
• 当前环境是运行在VMware内存中的RHEL Live OS，根文件系统为内存临时文件系统叠加只读系统镜像实现，默认不支持trusted类扩展属性写入，因此处理需要写入该属性的镜像层时直接抛出operation not supported错误，触发逻辑和NFSv3不支持扩展属性的报错完全一致。
• 执行df -h /home返回挂载点为rootfs，也印证了/home目录位于内存系统根命名空间下，没有落在支持完整扩展属性的独立ext4/XFS块设备分区上。

根据场景选择以下任意一种方案即可修复：

方案1：切换存储驱动为vfs（最适配临时内存OS场景） #

vfs存储驱动采用纯文件拷贝实现层逻辑，完全不依赖overlay扩展属性，兼容性最强，适合临时测试场景：

1. 清理现有Podman存储数据（该操作会删除所有已拉取镜像、容器、存储卷，执行前确认无留存数据）：

   podman system reset -f
   

2. 创建/编辑当前用户的Podman存储配置文件~/.config/containers/storage.conf，写入以下配置：

   [storage]
   driver = "vfs"
   

3. 重新执行podman run -it ubi8等命令即可正常启动镜像。
   该方案缺点是空间占用较高，每个容器层为全量文件拷贝，但在内存OS的临时测试场景下无明显影响。

方案2：将Podman存储目录迁移到支持xattr的独立分区 #

如果虚拟机挂载了独立的ext4/XFS格式块设备分区，可将Podman存储路径修改到该分区，保留overlay驱动的高性能和低空间占用特性：

1. 先执行podman system reset -f清理旧存储数据。
2. 编辑~/.config/containers/storage.conf，修改存储路径指向独立分区下的用户目录，例如独立分区挂载在/data：

   [storage]
   driver = "overlay"
   runroot = "/data/foo/run-containers"
   graphroot = "/data/foo/containers/storage"
   

3. 提前创建对应目录并将所有者设置为当前用户，再重新拉取镜像即可正常运行。

方案3：配置fuse-overlayfs忽略xattr写入错误 #

如果不想使用vfs驱动，也可以使用用户态fuse实现的overlay驱动，配置跳过不支持的xattr写入：

1. 安装fuse-overlayfs依赖：

   sudo dnf install -y fuse-overlayfs
   

2. 执行podman system reset -f清理旧存储。
3. 编辑~/.config/containers/storage.conf写入以下配置：

   [storage]
   driver = "fuse-overlayfs"
   [storage.options.overlay]
   ignore_xattr = true
   

4. 重新拉取镜像即可正常启动，该方案空间占用远低于vfs，仅性能略低于内核原生overlay。

内容的提问来源于stack exchange，提问作者Consumer of Cat Content