On Wed, Nov 5, 2008 at 2:18 PM, Brian J. Murrell <brian@xxxxxxxxxxxxxxx> wrote: > On Wed, 2008-11-05 at 14:02 -0500, J. Bruce Fields wrote: > >> Unfortunately that last option's the only practical approach right now. > > Other than exporting / of course. > >> We're working to simplify this. > > Great. > >> If you want to. If you want to just mount the whole of / at one point >> in the client filesystem, you can also do that, and the client will >> automatically mount the filesystems underneath as it traverses into >> them. > > That is cool. > >> > / 10.75.22.0/24(sec=krb5,ro,insecure,sync,wdelay,no_subtree_check,root_squash,fsid=0,crossmnt) >> > /home 10.75.22.0/24(sec=krb5,rw,no_root_squash,sync,no_subtree_check) >> > /d 10.75.22.0/24(sec=krb5,rw,no_root_squash,sync,no_subtree_check,crossmnt) >> > /d/sub pc(sec=krb5,rw,no_root_squash,sync,no_subtree_check) >> > >> > and on the clinet: >> > >> > pc # mount -t nfs4 -o sec=krb5 server:/ /mnt/server >> > pc # mount -t nfs4 -o sec=krb5 server:/home /mnt/server/home >> > pc # mount -t nfs4 -o sec=krb5 server:/d /d >> > pc # mount -t nfs4 -o sec=krb5 server:/d/sub /d/sub >> > >> > To have /home rw under /mnt/server. It would be there but ro without >> > the second mount, yes? >> > >> > It also appears that for the above case of /d and /d/sub I need the >> > crossmnt option on /d or I don't see anything in /d/sub even though I've >> > exported and mounted it individually. Does this seem like the expected >> > behaviour or a bug? >> >> That's expected. > > But causes a problem as below... > >> > It's important to be able to do because I might >> > want to be able to export /d to certain hosts without giving them access >> > to mountpoints within /d as I have done above with /d/sub and pc. If I >> > use crossmnt which my experience is showing I need, then /d/sub is >> > exposed to all of 10.75.22.0/24 which is not what I want. >> >> If you add a separate export for /d/sub, I think it should override that >> behavior. > > That's what I did and still, I have to use crossmnt on /d and that > exposes /d/sub it to everyone who gets access to /d where my intention > is to only expose /d/sub to the match/limit I put on /d/sub, which is > the single host "pc" in my above scneario. > A better way to limit access is to use ACL's on the directory, which actually make a difference when running kerberos. :) -->Andy > Let me thank you for all of your great answers. > > b. > > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
