New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XBMC cant not access bind mounted directories. #37

Closed
Kerwood opened this Issue Oct 29, 2013 · 5 comments

Comments

Projects
None yet
2 participants
@Kerwood

Kerwood commented Oct 29, 2013

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.

@sahlberg

This comment has been minimized.

Show comment
Hide comment
@sahlberg

sahlberg Oct 31, 2013

Owner

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
a filesystem (mount) boundary.
So for example if you yopu have one filesystem mounted at /export and a second filesystem mounted at /export/other
Then if on a client you only mount /export then the /export/other directory will look like an empty directory and you can not access any of its content. It looks just like an empty directory.

In NFS clients you workaround this by mounting BOTH /export and also explicitely mount /exports/other
which makes the client know that /export and /export/other are two different filesystems and then the client will handle the traversal between the two filesystems.

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.
You can even check it in wireshark and see that when using NFSv3 using the READDIRPLUS command the server returns that there are no entries w
hen you try to list the directories that are bind mounted on the server.

IF you mount on the client using nfsv4 all is probalby going to be good.
IF you mount on the client forcing v3 you will have to manually mount both /exports as well as /exports/folder1 (and 2)

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.
It would be really painful to try to detect and workaround this nfsv3 weirdness.

I think your problem is described here :

http://docstore.mik.ua/orelly/networking_2ndEd/nfs/ch06_02.htm

as the second rule.

It is certainly possible to try to automatically detect and workaround this "quirk" in NFSv3 in libnfs
but I would like to avoid it. It would be both painful and error prone :-(

Owner

sahlberg commented Oct 31, 2013

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
a filesystem (mount) boundary.
So for example if you yopu have one filesystem mounted at /export and a second filesystem mounted at /export/other
Then if on a client you only mount /export then the /export/other directory will look like an empty directory and you can not access any of its content. It looks just like an empty directory.

In NFS clients you workaround this by mounting BOTH /export and also explicitely mount /exports/other
which makes the client know that /export and /export/other are two different filesystems and then the client will handle the traversal between the two filesystems.

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.
You can even check it in wireshark and see that when using NFSv3 using the READDIRPLUS command the server returns that there are no entries w
hen you try to list the directories that are bind mounted on the server.

IF you mount on the client using nfsv4 all is probalby going to be good.
IF you mount on the client forcing v3 you will have to manually mount both /exports as well as /exports/folder1 (and 2)

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.
It would be really painful to try to detect and workaround this nfsv3 weirdness.

I think your problem is described here :

http://docstore.mik.ua/orelly/networking_2ndEd/nfs/ch06_02.htm

as the second rule.

It is certainly possible to try to automatically detect and workaround this "quirk" in NFSv3 in libnfs
but I would like to avoid it. It would be both painful and error prone :-(

@sahlberg sahlberg closed this Oct 31, 2013

@sahlberg

This comment has been minimized.

Show comment
Hide comment
@sahlberg

sahlberg Oct 31, 2013

Owner

To update.

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

/dev/sda1 /exports
/dev/sdb1 /exports/foo1
/dev/sdc1 /exports/foo2

Then if you only mount
mount server:/exports /exports
on oyur client both /exports/foo1 and /exports/foo2 will appear as empty directories.
The reason is that the v3 server will not allow you to use NFS to "jump" from one filesystem to another.

So in this case you need to mount all three filesystems on the client 👍
mount server:/exports /exports
mount server:/exports/foo1 /exports/foo1
mount server:/exports/foo2 /exports/foo2

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. :-(

Owner

sahlberg commented Oct 31, 2013

To update.

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

/dev/sda1 /exports
/dev/sdb1 /exports/foo1
/dev/sdc1 /exports/foo2

Then if you only mount
mount server:/exports /exports
on oyur client both /exports/foo1 and /exports/foo2 will appear as empty directories.
The reason is that the v3 server will not allow you to use NFS to "jump" from one filesystem to another.

So in this case you need to mount all three filesystems on the client 👍
mount server:/exports /exports
mount server:/exports/foo1 /exports/foo1
mount server:/exports/foo2 /exports/foo2

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. :-(

@sahlberg

This comment has been minimized.

Show comment
Hide comment
@sahlberg

sahlberg Oct 31, 2013

Owner

In theory, adding the 'nohide' option to the exports on your server could make this work.
I have not had much success myself with 'nohide' but it IS available on at least linux based servers and it might mork (according to 'mount exports')

Owner

sahlberg commented Oct 31, 2013

In theory, adding the 'nohide' option to the exports on your server could make this work.
I have not had much success myself with 'nohide' but it IS available on at least linux based servers and it might mork (according to 'mount exports')

@Kerwood

This comment has been minimized.

Show comment
Hide comment
@Kerwood

Kerwood Oct 31, 2013

Thank you very much for your time.
Even tough there is no solution for v4, it is nice to know why. (Side note: the nohide option does not work)

My konklusion is as follows.
Use NFSv3 methods, for XBMC's built in NFS share detection.
If I want to use v4, I'll have to manually mount file v4 filesystem to my local filesystem and add a "local directory" to XBMC.

Kerwood commented Oct 31, 2013

Thank you very much for your time.
Even tough there is no solution for v4, it is nice to know why. (Side note: the nohide option does not work)

My konklusion is as follows.
Use NFSv3 methods, for XBMC's built in NFS share detection.
If I want to use v4, I'll have to manually mount file v4 filesystem to my local filesystem and add a "local directory" to XBMC.

@sahlberg

This comment has been minimized.

Show comment
Hide comment
@sahlberg

sahlberg Jan 18, 2015

Owner

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.
Once you try to access a directory that is a submount, libnfs will then internally subsistute your path with the path to the nested mount.

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
/data
/data/foo and
/data/bar

But, on the libnfs/xbmc/kodi side, you now only need to mount/use /data
and libnfs will internally take care of that /data/foo and /data/bar are actually different filesystems.

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.

Owner

sahlberg commented Jan 18, 2015

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.
Once you try to access a directory that is a submount, libnfs will then internally subsistute your path with the path to the nested mount.

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
/data
/data/foo and
/data/bar

But, on the libnfs/xbmc/kodi side, you now only need to mount/use /data
and libnfs will internally take care of that /data/foo and /data/bar are actually different filesystems.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment