I am trying to apply an overlay using overlayfs over a filesystem mounted with archivemount:

mkdir -p {upper,work,mount}
tar zcf somefile upper/ work/ mount/
mkdir tmp
archivemount -o allow_root -o fsname=ext4 somefile tmp
sudo mount -t overlay -o lowerdir=/,upperdir=tmp/upper,workdir=tmp/work overlayfs tmp/mount

However, mount fails with:

mount: /tmp/test8/tmp/mount: wrong fs type, bad option, bad superblock on overlayfs, missing codepage or helper program, or other error.

Looking at dmesg, I see:

overlayfs: filesystem on 'tmp/upper' not supported as upperdir

Why would archivemount not supported? Is there a way around that problem?

1 Answer 1


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.)

  • I missed that bit of the tar documentation. I tried it and it didn't help. Note that archivemount man page also mention extended attributes, but only for MacFUSE. I don't know if it means that they enabled by default on linux or they are just not supported on linux. Dec 9, 2018 at 20:04
  • 1
    @LukeSkywalker Looking at the code, it doesn't seem like archivemount supports extended attributes, since the functions that would implement them are commented out. Looking at the code, there are no references to d_type either, so it seems it doesn't implement that either...
    – filbranden
    Dec 9, 2018 at 22:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .