On Wed, Oct 12, 2016 at 5:29 PM, Linus Lüssing <linus.luessing@xxxxxxxxx> wrote:
> Hi,
>
> I'm currently trying to spice up an NFS share by adding an overlay
> fs layer.
>
> As I only found a note regarding issues with using an overlay on
> the NFS client side in Documentation/filesystems/overlayfs.txt,
> I thought I'd ask about the NFS server side here.
>
>
> Instead of booting from a /srv/nfs/debian-sid/.amd64,
> I want to boot from an overlay like:
>
> /srv/nfs/debian-sid/.amd64 + /srv/nfs/debian-sid/overlay
> = /srv/nfs/debian-sid/amd64
>
> This overlay is constructed on the NFS server side.
>
>
> Without this overlay, things work for me:
>
> /etc/exports:
> /srv/nfs *(ro,async,no_root_squash)
>
> And mounting that with a kernel parameter like:
> ... ro root=/dev/nfs net.ifnames=0 ip=:::::eth0:dhcp \
> nfsroot=172.23.208.16:/srv/nfs/debian-sid/.amd64 ...
>
> As well as some more overlay magic in the initrd on the client
> side to add a tmpfs over the read-only NFS share. This part works
> so far.
>
>
> Now I'm trying to add an overlayfs on the NFS server side too,
> as described above. Unfortunately, this fails on the
> nfs-root-booting client side:
>
> ~~~
> [...]
> mount call failed - server replied: Permission denied.
> Begin: Retrying nfs mount ... mount call failed - server replied: Permission denied.
> done.
> Begin: Retrying nfs mount ... mount call failed - server replied: Permission denied.
> done.
> [...]
> ~~~
>
>
> I also tried changing the export from /srv/nfs to
> /srv/nfs/debian-sid/amd64, but I still get the permission denied.
> The overlay /srv/nfs/debian-sid/amd64 looks fine and with an empty
> /srv/nfs/debian-sid/overlay directory identical to the .amd64 one.
>
>
> NFS server side runs a Debian Jessie with a 4.7.0-0.bpo.1-amd64
> kernel. The NFS client side runs a 4.7 kernel, too, and is
> supposed to boot a Debian Sid.
>
>
> Any idea why this permission denied might happen?
>
You should be examining kmsg of the server machine.
Not sure why the client gets a Permission denied error, but the fact is that
exporting overlayfs is not supported.
I suppose that is all you wanted to know, but while I'm at it, I'll continue
the "what if" line of though.
check_export() in fs/nfsd/export.c says:
/* There are two requirements on a filesystem to be exportable.
* 1: We must be able to identify the filesystem from a number.
* either a device number (so FS_REQUIRES_DEV needed)
* or an FSID number (so NFSEXP_FSID or ->uuid is needed).
* 2: We must be able to find an inode from a filehandle.
* This means that s_export_op must be set.
*/
overlayfs does not qualify for the first requirement, which is hard to
fix, but can be circumvented from userspace.
overlayfs does not qualify for the second requirement either, which is where
things get interesting.. although the general case of any overlay combination
is hard to fix, there is a simpler case of lower and upper on the same sb
and that sb has s_export_op (which is the case in your setup).
In that case, I think it shouldn't be too hard to implement the export ops.
The question is what happens after copy-up.
My first instinct is to always identify the inode by lower inode handle,
unless it is a pure upper, same approach that Miklos took in recent patch
ovl: make directory ino/dev numbers stable
If there is interest I could probably look into this.
Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
