The documentation for the overlayfs kernel module states:
The upper filesystem will normally be writable and if it is it must support the creation of trusted.*
extended attributes, and
must provide valid d_type
in readdir
responses, so NFS is not suitable.
So archivemount
probably doesn't implement either one of these features, which makes it unsuitable for use as a upper layer in a writable overlayfs.
Note that the documentation continues with:
A read-only overlay of two read-only filesystems may use any filesystem type.
So if a read-only overlayfs is enough for your needs, setting it up on top of archivemount
should work even for the lower layer, just having to mount everything read-only for that case.
Note that there aren't limitations in the FUSE protocol itself that make any FUSE mounts unsuitable for use as a writable upper layer in overlayfs.
Specifically, FUSE exposes functions to query and set extended attributes and it also exposes the d_type
field for implementations to fill.
But specific FUSE applications need to implement those features for them to be available.
Regarding extended attributes, a separate technical limitation for archivemount
is that not all archive formats support storing extended attributes, so it's possible even if archivemount
would implement support for extended attributes, that it would not be available on all supported archive formats.
(See documentation for --xattrs
option of GNU tar for some more details.)