Closed ikogan closed 9 years ago
I do not see that PR to OMV core making it. That's a specific way of changing nfs behaviour, not everybody would want that. I think volker idea would be to add an environmental variable to change the mount bind options, like is done in other FS to remove the noexec flag (globals.inc). That's more a generic approach, or add a checkbox to mount (export) recursive sub filesystems in the nfs window, this is my opinion in case you want to reconsider the patch you're sending to the bugtracker.
For the zfs PR request you have to wait to @nicjo814 or @mir07 to see their opinion.
As I'm discovering, there are a few issues with this I didn't consider. Apparently rbind
only works when it's mounted. Subsequent filesystems added will not automatically be "bound" as well. In addition, there are several mkcconf scripts that specifically check for bind/not bind so modifying core isn't quite so simple.
It looks like this is actually going to have to create mntent entries for each child filesystem or create an fstab mkconf script to add a bind mount for each child.
I've updated this to create additional fstab entries rather than relying on rbind. I still need to do a bit of testing on it tomorrow before I'm happy with it.
Sorry for the late reply. I'm really excited to see development on this plugin, since it's been quite slow progress lately. I'll test it as soon as you consider it ready. Does it still rely on changes to OMV core?
It doesn't any longer. Originally I wanted to change core to use "rbind" but then found that rbind only binds child mounts at mount time so you'd need to remount them all after creating a new child filesystem. Instead, I decided to handle making changes to fstab and mounting/unmounting inside the plugin so no core changes are required.
With the latest update this pull request, I believe this might be ready for testing. It seems to correctly manage my exports, fstab, and mounts. The only minor concern I have if an nfs share is in use. I might need to add something in there to ensure that the NFS config script runs first if that's not happening already.
Is there anything else that needs to be done for this to be merged? It's been working fairly well for me so far.
I had to re-introduce the insserv override which did introduce some conflicts (minor I think)... Could you just rebase with master branch and then I'll merge?
That should do it I think?
Could you remove the preinst again? I removed it since it was incorrectly introduced to begin with... You haven't added anything to it?
Do you need the preinst script for anything, or can I remove it?
I've removed it.
Currently, if you have a filesystem structure like the following:
And you attempt to share
Data/Homes
,Data/Homes/user1
will be an empty folder on all clients. To solve this problem, a new/etc/exports
entry must be created for each nested filesystem and a new fstab entry must be created to bind the filesystems into the/exports
export root. This PR achieves that with an nfs.dmkcconf
script and a fstab.dmkcconf
script. It also adds a small settings panel to configure this behavior.While ZFS has it's own way of setting up NFS shares (the
sharenfs
property), it seems that it doesn't quite work as well as the ZFS developers would like and, in the current release version, doesn't support setting Kerberos options on shares. There is an issue for that here: https://github.com/zfsonlinux/zfs/issues/3738#issuecomment-139658973 including patches that make it work but there's some dialog as to changing how sharing is handled entirely so whether or not that change get integrated is unknown. It may better to move to whatever the ZFS team decide is the best practice for NFS shares whenever that happens. For the time being, there's this solution.