Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
XBMC cant not access bind mounted directories. #37
Hi.. Im having an issue, and i think it relates to libnfs.
Im trying to setup my NFS mounts the NFSv4 way, with only one exported folder and the others, that I want to share, bind mounted into the exported folder.
See link for more details. http://forum.xbmc.org/showthread.php?tid=176446
Is this not supported in libnfs or am i doing it wrong?
Thank you very much for your time and effort on this project.
libnfs is a userspace nfsv3 implementation. It accesses nfs shares directly across the network without any interactions with the host os.
Libnfs only supports nfsv3 and no immediate plans exist for v4 at this time. Mainly due to the vast amount of work it would require.
NFSv4 handles "nested filesystems" a lot better than NFSv3.
In NFSv3, clients use clientside caching and write-back, for performance reasons. But there is no cache coherency protocol in NFS, so this all is highly dangerous but there are some policies in NFSv3 servers that apply to make it a lot less dangerous.
One of the things that NFSv3 servers do to make things more safe is that they not allow a NFS operation to cross
In NFS clients you workaround this by mounting BOTH /export and also explicitely mount /exports/other
It is all messy and NFSv3 not really all that good :-(
You can reproduce it by mounting and forcing version 3, and you will see that the bind mounted directories can no longer be seen, they are empty.
IF you mount on the client using nfsv4 all is probalby going to be good.
Unfortunately we don't have anything in libnfs to do multiple mounts and traverse filesystem/mount boundaries today. :-(
In XBMC, the easiest solution is that you just make it access both of the /exports/folder1|2 instead of the parent directory that sits in a different filesystem.
I think your problem is described here :
as the second rule.
It is certainly possible to try to automatically detect and workaround this "quirk" in NFSv3 in libnfs
This is unfortunately how nfsv3 works. You can only export filesystem by filesystem and an nfs mount can not traverse a filesystem boundary.
It is easy the test this by forcing nfsv3 on your client. (nfs v4 does this better by using a pseudo filesystem)
Say your server has these filesystems
Then if you only mount
So in this case you need to mount all three filesystems on the client
Thus making the client know where the filesystem boundaries are and the client doing the jump from one mountpoint to the other instead of the server.
This is very annoying in NFSv3 but there were good reasons at the days when these restrictions were added.
Try it by forcing nfsv3. It is very annoying behaviour in nfs v2 and v3. :-(
Thank you very much for your time.
My konklusion is as follows.
Blast from the past ...
If you are interested in trying out NFSv3 in libnfs again,
I have added code to libnfs to automatically track all nested submounts and automatically switch beteen then so that the application does not have to care about mounts.
The way it does it is by fetching a list of all mounts from the server during mount time and then build a mapping between the relative path between mounts and their associated filehandles and nfs attribute structures.
In order to make this work, you would still need to export both the parent and all the nested mounts from the server:
So if you have /data and then under /data you have two other filesystems foo and bar you would have to export all three of
But, on the libnfs/xbmc/kodi side, you now only need to mount/use /data
It is only available in the current master branch, but I intend to release this as a new version in a few weeks if all goes well.