Podman返回“错误处理焦油文件（退出状态1）：不支持操作” （无根）
启动图像高山和Ubuntu时，Podman可以（RHEL 8）。如果启动图像UBI8和Grafana/Grafana-oss，那么为什么
Error: writing blob: adding layer with blob "sha256:de63ba066b7c0c23e2434efebcda7800d50d60f33803af9c500f75a69fb76ffa": Error processing tar file(exit status 1): operation not supported
对某些图像而不是其他图像失败？这是无根完成的，但是网络文件系统没有发挥作用。完整输出：
$ whoami
foo
$ echo $HOME
/home/foo
$ df -h /home
Filesystem Size Used Avail Use% Mounted on
rootfs 7.9G 6.8G 1.2G 86% /
$ podman run -it ubi8
Resolved "ubi8" as an alias (/etc/containers/registries.conf.d/001-rhel-shortnames.conf)
Trying to pull registry.access.redhat.com/ubi8:latest...
Getting image source signatures
Checking if image destination supports signatures
Copying blob 1b890c73c3cf skipped: already exists
Copying blob de63ba066b7c done
Error: writing blob: adding layer with blob "sha256:de63ba066b7c0c23e2434efebcda7800d50d60f33803af9c500f75a69fb76ffa": Error processing tar file(exit status 1): operation not supported
看起来与NFS V3上的数据存储时，它看起来与之相似，但不是给出的错误。 （$ home是本地FS。）主机系统是在VMware VM上存储器中运行的OS图像。操作系统为RHEL8.6。内核= 4.18.0。
When starting the images alpine and ubuntu, podman works (RHEL 8). If starting the images ubi8 and grafana/grafana-oss, it fails with
Error: writing blob: adding layer with blob "sha256:de63ba066b7c0c23e2434efebcda7800d50d60f33803af9c500f75a69fb76ffa": Error processing tar file(exit status 1): operation not supported
Why is it failing with some images but not others? This is being done rootless, but a network file system is not in play. Full output:
$ whoami
foo
$ echo $HOME
/home/foo
$ df -h /home
Filesystem Size Used Avail Use% Mounted on
rootfs 7.9G 6.8G 1.2G 86% /
$ podman run -it ubi8
Resolved "ubi8" as an alias (/etc/containers/registries.conf.d/001-rhel-shortnames.conf)
Trying to pull registry.access.redhat.com/ubi8:latest...
Getting image source signatures
Checking if image destination supports signatures
Copying blob 1b890c73c3cf skipped: already exists
Copying blob de63ba066b7c done
Error: writing blob: adding layer with blob "sha256:de63ba066b7c0c23e2434efebcda7800d50d60f33803af9c500f75a69fb76ffa": Error processing tar file(exit status 1): operation not supported
It looks similar to but is not the error given when trying to store data on NFS v3. ($HOME is a local fs.) The host system is an OS image running in memory on a VMware VM. The OS is RHEL8.6. Kernel=4.18.0.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
简短答案：主机文件系统类型是TMPFS（又称Rootfs），它与被用作容器的刮擦区域不完全兼容。添加
- storage-opt“ Overlay.mount_program =/usr/bin/fuse-overlayfs”围绕着。完整答案：这是不起作用的，因为将TMPFS（rootfs）用作主机系统的根文件系统。它用于存储容器的备份商店aka刮擦区域（配置文件变量：Graphroot），即存储图像，容器 - 位置文件系统等。运行图像以创建容器时，图像的文件系统和运行容器的文件系统合并到覆盖文件系统中。图像的文件系统在该覆盖范围内函数为“下级目录”，并且容器的文件系统作为“上层目录”的功能。 tmpfs（以及So rootfs）不允许所有XATTR（用户。*和受信任的。具体而言，由于XATTR问题，缺乏在上部文件系统上创建不透明目录的能力。一些图像，例如Ubi8和Grafana-oss，以预先存在的不透明目录启动，因此根本无法运行这些目录，也无法将其图像拉动。其他图像（例如高山和Ubuntu）没有这种限制。但是，一旦开始，这些容器由于XATTR问题而无法安装软件。最好使用XFS文件系统上的后备存储存储运行所有这些容器。但是，可以使用TMPF在TMPF上运行它们
- storage-opt“ oferlay.mount_program =/usr/bin/fuse-overlayfs”使用Fuse-overlayfs驱动程序的结果速度较慢，i/o较慢，因为数据必须通过FUSE层在往返内核的路上。如果对容器本地文件系统的性能不是问题，那么我认为这将是可以接受的解决方法。可以通过在主机系统上创建XFS文件系统并将备份存储器指向该目录，例如设置XDG_DATA_HOME来解决此问题。另外，这可以通过在主机系统的TMPF上创建一个包含XFS文件系统并安装的文件来实现。顺便说一句，NFS V3也有类似的问题。 Redhat已更新了Podman，以允许NFS V4用作后备商店。Short Answer: The host file system type is tmpfs (aka rootfs), which isn't fully compatible with being used as the scratch area for a container. Adding
--storage-opt "overlay.mount_program=/usr/bin/fuse-overlayfs"gets around that.Full Answer: This did not work because tmpfs (rootfs) was being used as the root filesystem of the host system. This was being used to store the container's backing store aka scratch area (config file variable: graphroot), i.e. to store images, container-local file systems, etc. When an image is run to create a container, the image's file system and the running container's file system are merged into an overlay file system. The image's file system functions in that overlayfs as the "lower directory" and the container's file system functions as the "upper directory." Tmpfs (and so rootfs) does not allow all the xattrs (user.* and trusted.*) necessary to function as the upper directory. Specifically, the ability to create opaque directories on the upper file system is absent due to the xattr issue. Some images, such as ubi8 and grafana-oss, start up with pre-existing opaque directories, so those cannot be run at all, nor their images pulled. Other images such as alpine and ubuntu do not have this limitation. However, once started, those containers cannot install software due to the xattr issue. It's best to run all these containers using a backing store that is on an XFS file system. However, it's possible to run them on tmpfs using
--storage-opt "overlay.mount_program=/usr/bin/fuse-overlayfs"A consequence of using the fuse-overlayfs driver is slower i/o due to data having to go through the FUSE layer on the way to and back from the kernel. If performance to the container's local file system isn't an issue, this would be an acceptable workaround in my view. It's possible to get around this issue by creating an XFS file system on the host system and pointing the backing store to that directory, e.g. by setting XDG_DATA_HOME. Alternatively this can be accomplished by creating a file on the host system's tmpfs that contains an XFS file system and mounting that. Incidentally, NFS v3 has a similar problem. Redhat has updated podman to allow NFS v4 to be used as the backing store.