Arch Linux

shutdown -h now

Member

Registered: 2012-11-07

Posts: 18

Can't export overlayfs with NFS

I have a working overlayfs in place and a working nfs setup. However when I try to export an overlayfs merged directory I get the following error:

exportfs: /srv/nfs4/overlay does not support NFS export

The relevant /etc/exports entries:

/srv/nfs4                 192.168.1.1/24(ro,no_subtree_check,fsid=root,crossmnt)
/srv/nfs4/overlay         192.168.1.1/24(ro,no_subtree_check,all_squash)

Is there a way to get this working?

A search shows that AUFS also can't be nfs-exported when the kernel parameter CONFIG_AUFS_EXPORT is not set and as such the external inode generation table is missing. Thought it might be relevant, however overlayfs doesn't seem to have any kernel config parameters.

Edit: The underlying filesystem is btrfs.

Last edited by shutdown -h now (2015-01-22 17:06:52)

WonderWoofy

Member

From: Los Gatos, CA

Registered: 2012-05-19

Posts: 8,414

Re: Can't export overlayfs with NFS

The documentation for OverlayFS states that "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." 

It sounds like those conditions are not met whether you try to use mounted NFS as the upperdir or if you try to then export the merged directory.

shutdown -h now

Member

Registered: 2012-11-07

Posts: 18

Re: Can't export overlayfs with NFS

You might be on the right track but that statement only says something about the requirements of the upper filesystem which is btrfs and as such fulfils both of these requirements.

Looking at the following exempt from the overlayfs documentation I would assume that NFS expects something that overlayfs doesn't offer, but my knowledge of filesystems is limited so I have no idea how to test this.

               [...] An overlay-filesystem tries to present a
filesystem which is the result over overlaying one filesystem on top
of the other.

The result will inevitably fail to look exactly like a normal
filesystem for various technical reasons.  The expectation is that
many use cases will be able to ignore these differences.

This approach is 'hybrid' because the objects that appear in the
filesystem do not all appear to belong to that filesystem.  In many
cases an object accessed in the union will be indistinguishable
from accessing the corresponding object from the original filesystem.
This is most obvious from the 'st_dev' field returned by stat(2).

While directories will report an st_dev from the overlay-filesystem,
all non-directory objects will report an st_dev from the lower or
upper filesystem that is providing the object.  Similarly st_ino will
only be unique when combined with st_dev, and both of these can change
over the lifetime of a non-directory object.  Many applications and
tools ignore these values and will not be affected.

Last edited by shutdown -h now (2015-01-23 10:37:37)

WonderWoofy

Member

From: Los Gatos, CA

Registered: 2012-05-19

Posts: 8,414

Re: Can't export overlayfs with NFS

Well the way i see it, you can't use it as an upper filesystem because it doesn't support the creation of trusted.* extended attributes, and must provide valid d_type in readdir (as the documentation states).  But when you export those filesystems via NFS, mounting on the client side will again not support the creation of trusted.* extended attributes, and must provide valid d_type in readdir, so you are in the same boat I think.

You would probably want to ask something like this on the appropriate mailing list or IRC channel though.  You might even be able to go ask the OpenWrt folks since they have been using OverlayFS for quite some time.