NFSv4 Support

[Aparajita Raychaudhury]

The last word I can find on it is https://github.com/sahlberg/libnfs/issues/20 - written in 2012. "I have littel interest in v4 so I dont plan to add it. But anyone is welcome to send patches to add support."

Has someone worked on this? Is there any possibility of v4 support coming somewhere in the near future?

[ronnie sahlberg]

On Fri, Jul 17, 2015 at 2:10 AM, Aparajita Raychaudhury <apara...@gmail.com> wrote:

The last word I can find on it is https://github.com/sahlberg/libnfs/issues/20 - written in 2012. "I have littel interest in v4 so I dont plan to add it. But anyone is welcome to send patches to add support."

Has someone worked on this? Is there any possibility of v4 support coming somewhere in the near future?

Not that I am aware of.

Which particular protocol features of NFSv4 do you need that is not available in NFSv3 ?

[Étienne Qusslr]

Happy new year :D

I personnally have major struggles exporting a FUSE-based mount through NFSv3.

From what I gather here and there NFSv3 doesn't allow exporting Fuse mounts...

While NFSv4 does. That would be one of the features I lack.

[ronnie sahlberg]

Hi,

It is not just FUSE, re-exporting of NFSv3 is quite fragile in general
and not really allowed.
Due to how NFSv3 clients often do caching, NFSv3 re-exports can/will
cause dataloss and corruption if the client can see both the original
share as well as the re-exported share. You can test this by just dong
a normal kernel mount and try exporting it. Kernel will not allow it.

That said, I recall exporting fuse filesystems through knfsd a long
time ago by tweaking the /etc/exports file.

Try specifying fsid in the /etc/exports file for your exports.
fsid=1234 for the first fuse share, fsid=1235 for the second, ...


This used to confuse knfsd enough that it would no longer know that it
was a fuse filesystem and thus allow the export to happen.

The same trick used to work when you wlikelanted to export both a
directory and a subdirectory (in the same filesystem) as two different
exports. (This is also not allowed in NFSv3 for the same reasons.)



Let me know if the fsid trick works for you. If not I can try
experimenting to see if there are other workarounds available.

IF it works, make absolutely sure that you NEVER mount both the
original share and the re-export on the same client since this will
very likely case file corruption!

> --
> You received this message because you are subscribed to the Google Groups
> "libnfs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to libnfs+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Etienne Quesselaire]

Hello Ronnie,

Thanks for your reply. I just tried, full of hope (:D), your trick, but
unfortunately it didn't work.


Here's my /etc/exports:
/media/Photos
*(rw,no_subtree_check,insecure,anongid=100,anonuid=1001,all_squash)
/media/Vidéos
*(fsid=1234,rw,no_subtree_check,insecure,anongid=100,anonuid=1001,all_squash)
/media/Musique
*(fsid=1235,rw,no_subtree_check,insecure,anongid=100,anonuid=1001,all_squash)


Just to give a little bit more background, here's my setup:

- the problem I have is with the embedded NFS client from Kodi/Android
- /media/Photos is a bind-mount from a subfolder of a non-FUSE mount point
- I'm using MHDDFS (but it does the same with mergerfs, both are FUSE)
- using systemd (ubuntu 15.10, I had race conditions with the fstab
conversion to systemd), I first mount the MHDDFS pool to /mnt/pool. It
has 2 subfolders (Musique & Vidéos).
- I then bind-mount both of the subfolders to /media/Vidéos & /media/Musique
- this setup works with the embedded NFS client from Kodi under Openelec
(do you have an idea why it is so?)

I am not sure, what do you mean by "re-exporting"?

Thanks!
Etienne

[ronnie sahlberg]

It works here.
10.0.0.1 is the NFS server where I have all the data.
10.0.0.2 is where I run FUSE and then re-export the FUSE filesystem as
NFS again :


On the server where I will FUSE mount the share, and then re-export it :
1, Mount the share locally using fuse-nfs on /mnt:
sudo ./fuse/fuse-nfs --allow-other --nfs-share=nfs://10.0.0.1/foo
--mountpoint=/mnt

Then just verify that the share mounted just fine and that we can
access the data:

mount | grep fuse-nfs
fuse-nfs on /mnt type fuse.fuse-nfs
(rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Looks good, we can see the mount.


ls /mnt
...

Looks good, I can see the content of the share.


2, Set up NFS so that we re-export the /mnt share

Adding this line to /etc/exports:
/mnt *(ro,insecure,no_root_squash,fsid=123)

Restart the kernel nfs server:
sudo /etc/init.d/nfs-kernel-server restart



3, Mount the NFS exported FUSE filesystem on the client:
On the client where I will mount the FUSE export:

Checking nfs with userspace
nfs-ls nfs://10..0.0.2/mnt
... the content of my share ...

Looks good. I could access the data in the exported FUSE filesystem
using nfs-ls (userspace nfs)

Now try mounting it on the client using the normal nfs client in the kernel:
sudo mount 10.0.0.2:/mnt /mnt
ls /mnt
... the data I expect ...

So it works for me at least.


I have kernel 3.18.0 but I it has been possible to export a FUSE
filesystem since at least ~6 years ago.
This project kind of depended on being able to export a FUSE
filesystem via NFS :
https://git.samba.org/?p=sahlberg/remote-cache.git;a=summary