I have a v3020 device running OnTap 7.2.3 with NFS exporting vol0/etc$ for monitoring purposes. I have started to have problems when I installed CIFS and run the CIFS wizard. My monitoring script stopped working because it couldn't access vol0/etc$ anymore. I did some investigation and I found out that the qtree for vol0/etc$ was set to NTFS. I changed to UNIX (and even MIXED) but I still had problems. In the end I realised that the files permissions for vol0/etc$ were all set to 0. Accessing vol0/etc$ from CIFS works fine but I would like to fix the NFS permissions as they were originally. There are quite a lot of files and I was looking for a quick fix or at least automated.
Most likely there are ACLs on those files so the 000 permissions aren't real. You've got a couple of options here.
If you want UNIX style security, then you'll want to chmod the files to what you want (even -R or * should do the trick).
If you want NTFS permissions, then make sure your user mapping are good such that you can access the data. Your NFS user will be mapped to a Windows user and the permissions enforced that way. In this mode, you can basically ignore the UNIX permissions because they aren't used anyway.
The best choice is the side that you want to be able to *change* permissions. Pick the side where you want that to happen and then choose the security style accordingly.
Keep in mind that by default /vol/vol0/etc is usually not a qtree (it should be, IMHO), so you may end up having to change the permission on the root qtree /vol/vol0/ <- note the trailing /. Unless you've converted it to a qtree.
I have installed CIFS only because I was messing about with a Windows SnapDrive and I needed to do some tests with iSCSI. Because SnapDrive connects to the NetApp box using RPC by default I found out that the only way for RPC to work was to install CIFS. So I did and probably have inadvertently chosen the NTFS only option. Later I found out how to connect SnapDrive using https but that was too late.
I just want to put the box back to its original condition with the vol0/etc$ NFS export having all those files back to their original permissions. I don't really care about CIFS at this point in time and in fact I have disabled it. It is important that the vol0/etc$ export works because this box is part of a cluster which is supposed to take over the other node if it fails. This is why we need to monitor the boxes (we are using a product called big-brother from a Unix server) and the monitoring for this box stopped working. We could change the permissions for just the file we need (and in fact we actually did) but I am wondering: is the device is a state able to support a live service as it is now? I believe so but some of my colleagues are a bit more skeptical.