I'm trying to migrate our CentOS Kickstart environment from a Solaris server to a NetApp FAS 2040 running ONTAP 7.3.2, but am not having much luck. Specifically, I'm getting stuck on finding the /etc/exports rule that is needed to allow anonymous read-only access from any client and to allow read/write access from a specific group of clients (a netgroup) for the /vol/public volume (which contains the Kickstart configuration file). I've tried a couple of different combinations so far:
The outcome of this is that a Kickstart works, but the files cannot be edited (as expected).
The outcome of this is that systems in nfs-all-rw can edit the files, but a Kickstart does not work. Note that even for systems in nfs-all-rw, a Kickstart results in permission denied (not expected). Systems not in nfs-all-rw also fail to Kickstart (as expected).
This was an attempt to combine the two rules. As I understood from man na_exports, if multiple security flavors are specified then that security flavor is used for all following options until the next security flavor is specified. The Kickstart environment gives pretty lousy debugging information (it just says permission denied), but a packet capture of the session shows that the NFS export gets mounted on the client, but then the NetApp filer denies access to the file (18.104.22.168 is a member of nfs-all-rw, 22.214.171.124 is the NetApp filer):
This boggles me, since permissions on the file are 664 and permissions on all directories leading up to the file are 775. Any idea what could be wrong?
For what it's worth, the Solaris NFS server that we're trying to migrate away from uses sec=sys,ro as NFS export options. Obviously that doesn't allow us to modify the files over NFS, so we just edit the files on the Solaris system itself; unfortunately we don't have that capability with the files stored on a NetApp filer.
Sometimes you just need a second pair of eyes. That does in fact work, although sec=sys,ro is a little bit less secure than sec=anon,ro. I don't think it will matter in this case since we're not dealing with sensitive data. Thanks! (And sorry for the long delay in responding).