If fuse-overlayfs is used with a writable overlay, it should always be used in future. #3177

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.