Version of Singularity
main / 4.1
Describe the bug
While investigating #3176 it has become apparent that my understanding of native overlay vs fuse-overlayfs compatibility is incorrect. Even where xattr support and creation of 0:0 char devices is available, fuse-overlayfs can create overlays that will not mount with the same content under native overlayfs.
When checking whether a directory is opaque, fuse-overlayfs inspects things in the following order:
- native overlay privileged xattr
- native overlay unpriviliged xattr
- fuse-overlayfs xattr
- presence of
.wh..wh..opq file.
When creating an opaque directory, fuse-overlayfs:
- Tries to set the native overlay privileged xattr
- If this fails, tries to set the fuse-overlayfs xattr
- always creates a
.wh..wh..opq file
Note that the native overlay unprivileged xattr is never set... so if fuse-overlayfs is used in a context where the unprivileged xattr would be set by native overlayfs, then it will generate a filesystem incompatible with native overlayfs.
Version of Singularity
main / 4.1
Describe the bug
While investigating #3176 it has become apparent that my understanding of native overlay vs fuse-overlayfs compatibility is incorrect. Even where xattr support and creation of 0:0 char devices is available, fuse-overlayfs can create overlays that will not mount with the same content under native overlayfs.
When checking whether a directory is opaque, fuse-overlayfs inspects things in the following order:
.wh..wh..opqfile.When creating an opaque directory, fuse-overlayfs:
.wh..wh..opqfileNote that the native overlay unprivileged xattr is never set... so if fuse-overlayfs is used in a context where the unprivileged xattr would be set by native overlayfs, then it will generate a filesystem incompatible with native overlayfs.