You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a bug in containerd/continuity#244 where CopyDir() fails on filesystems without xattrs. The syscall to list xattrs will fail with ENOTSUP, and continuity will treat it as a regular error and say it failed. When creating a container, if there are volumes to mount, nerdctl will make a call to this CopyDir() function. This is a problem for us, since by default we disable xattrs unless whiteout directories or file xattrs are detected.
For now we can have xattrs be on by default and allow this change to be opted into, but we should either wait for the upstream bug fix (which could take a long time) or find a somewhat elegant workaround in SOCI.
Steps to reproduce the bug
Pull image with a layer that has a volume mount without whiteout dirs or xattrs. (ARM64 for rabbitmq@sha256:19e69a7a65fa6b1d0a5c658bad8ec03d2c9900a98ebbc744c34d49179ff517bf worked for this.)
Create SOCI index with xattrs optimization enabled.
Push to registry
Pull from registry with SOCI and attempt to run container
Describe the results you expected
Container should run instead of erroring with "operation not supported"
Host information
OS: Linux
Snapshotter Version: v0.6.1
Containerd Version: v1.7.18
Any additional context or information about the bug
No response
The text was updated successfully, but these errors were encountered:
Description
There's a bug in containerd/continuity#244 where CopyDir() fails on filesystems without xattrs. The syscall to list xattrs will fail with ENOTSUP, and continuity will treat it as a regular error and say it failed. When creating a container, if there are volumes to mount, nerdctl will make a call to this CopyDir() function. This is a problem for us, since by default we disable xattrs unless whiteout directories or file xattrs are detected.
For now we can have xattrs be on by default and allow this change to be opted into, but we should either wait for the upstream bug fix (which could take a long time) or find a somewhat elegant workaround in SOCI.
Steps to reproduce the bug
rabbitmq@sha256:19e69a7a65fa6b1d0a5c658bad8ec03d2c9900a98ebbc744c34d49179ff517bf
worked for this.)Describe the results you expected
Container should run instead of erroring with "operation not supported"
Host information
Any additional context or information about the bug
No response
The text was updated successfully, but these errors were encountered: