2011-05-26 01:08 AM
we 've got an new FAS2040 (active/active) and it is our first NetApp-system. So we've not a lot of experience with those systems.
Actually I've got a problem with CIFS-Shares. One of the filers (named na204012) works fine and I am able to create volumes, qtrees, shares on the filer and offer them by using the MMC.
On the other filer (named na204011), I am also able to create, but if I want to work with the MMC to create new Shared Folders I got the message "You do not have permissions to see the list of shares for Windows clients."
I can't find difficulties between both nodes. The share permissions of the created shares on the filer are identical (by the way, what are the best share permissions at this time ? - we made a new group "servadmin" role = "power" for our domain- and server-admins, and a group "sanadmin" role = "admin" for our storage-admins).
Any idea ?
2011-05-26 06:43 AM
I see no one has jumped at this one yet and I can understand that to some extent because permission problems can be a real pain to diagnose via "blogs".
Your basic "bible" for network file sharing protocols for your release can be find on the NOW site. The File Access and Protocols Management Guide
Basically, you can use a few options settings and the system messages file to get more information. Since I rarely use the http interface (it is just not exact enough in all situations), you might want to try 'options cifs.trace_login on' (just use "off" to turn it off afterwards) on both filers to see what is different. Entering "options cifs" will show you all options in the cifs "tree" of options.
Having said that, a lot depends on a number of other factors too: multi-protocol filer (nfs and cifs?)?, qtree security?, cifs guest access options, options for admin access to shares, share browsing options, acces-based enumeration, authentication with AD... etc.
As far as share permissions, as long at you are running ntfs security style, you really don't need them. The underlying file system permissions are basically enough to work with. You might want to have an "admin" share pointing to the netapp vol above your cifs share (really a good idea to point CIFS shares to qtrees) so you can set filesystem permissions on the qtree (functions like a windows directory/folder for this)a.
Local users can be problematic if you don't have an overview of all the roles and capabilities (terribly documented, unfortunately). You probably, if your organization is realatively small or your admin groups are pretty specific, can get away with simply adding your AD admin group to the filer in the administrators group, like this:
useradmin domainuser add AD\my_AD_admins_with_clue -g Administrators
on the command line.
For the rest of the problems, I guess you are going to need to provide some more specific information: ONTap version, AD version, Windows version, SMB version, qtree security for the vol/qtree with cifs shares, output from relevant 'options cifs', output from 'cifs shares' for the problematic shares, etc...