The default can be anything you want, it doesn't have to be 0.0.0.0/0 ro.
Do keep in mind that the root mount needs to allow all the clients that need permissions for all the junction mounts below it.
I haven't played with qtree exports in cDOT, but the volume will need to have both host A and B and then you can have qtreeA and qtreeB limited to host A and host B. If the only thing in the root of the volume is qtreeA and qtreeB, all the hosts will be able to see is the name of the other qtree.
showmount isn't very useful with cDOT, unfortunately. Export changes take effect immediately, so no need to run exportfs -a any more.
Another thing to keep in mind is that exports are order dependent now. cDOT takes the first match, not the best match. I ran into this when doing some 7-mode transitions. The 7-mode export had "ro=172.16.1.0/24,rw=172.16.1.5:172.16.1.6:...." in that order, and when that was converted to cDOT, all the clients that should have been rw ended up ro. I moved the subnet match to the end and everything was back to normal.
John
On Tue, Nov 11, 2014 at 06:51:50PM -0800, Iluhes wrote:
Hi toasters, NFS export in CDOT (ouch) I understand I have to have a default policy and a rule..
- Must it have 0.0.0.0/0 read only? What if I dont want to give read-only to entire name space to all clients?
- Qtrree exports: can I restrict qtree A to host A, and qtree B to host B, but then what about volume and it is policy? Can qtree be more restrictive than volume (and why dont qtree show up in GUI?)
- Does showmount -e LIF of NFS filer still produce good information. It does not look like, so how do I check what my exports are?
- What does it buy me with qtree exports, what? If I have to give access to server A and B to volume that has qtree A and B
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters