I don't know of any simplified way. I've migrated shares and share permissions before by using the /etc/cifsconfig_share.cfg file. I can't at the moment recall if I copied it over and started cifs, or just ran each line in the file, since they are all valid cifs command.
After you do the cifs setup on the new controller, you could try copying all the /etc/cifs* files over that don't look complete on the new controller. cifsconfig_setup.cfg, for example, should be fully configured after you run cifs setup. I'm not sure about cifssec.cfg. Also check all the cifs options ("options cifs") and make sure the new controller is the same.
There are also some cifs shares settings in the registry, if you set things like umask and forcegroup - search for options.cifsinternal in /etc/registry, and you'd need to apply those manually (or via a script).
By reading your message, I am wondering what document I need to read through, in order to get understanding of these aspects of CIFS on NetApp filers, things like your said, use of /etc/cifsconfig_share.cfg, cifsconfig_setup.cfg, cifssec.cfg, /etc/registry etc...
Unfortunately I don't know of any document that really talks about how the files are used. I got this info by poking around the filesystem and piecing stuff together through trial and error. There are plenty of guides available on the NetApp support site, but I think they are all ready focused on the front end (cifs setup, cifs shares -add, etc) and not so much on the back end.
Your message made me feel better, I am not the only one for a new CIFS guy.
You reminded me to check out /etc/cifsconfig_share.cfg, and there are a lot of lines with the format as following:
cifs access "share_name" S-1-5-11 Change
Could you please elaborate more about what S-1-5-11 is? I guess, it might be something to do with authentication group in Active Directory. Is that true? and how this S-1-5-11 is define? Since I don't have the access to AD, what am I supposed to see about this name?
You are right - the S-1-5-11 is an AD identifier (SID) of a user and/or group. You don't really do anything with it - it's meaningless on the NetApp side. Only AD knows what it refers to. When the controller is connected to AD, AD manages the share permissions, which is why they reference the AD SID.
This share permission had to be created when AD was connected; otherwise the SID would be meaningless. You won't be able to see what the SID refers to from the filer if it's not connected to AD; if it is, you can use wcc -s <SID> to see what it maps to - but you shouldn't really care, as the permissions should be made and managed by the AD guys.
cifs lookup appears to work better than wcc for me in translating SIDs. Also, I misspoke when I said the SIDs were only AD; the builtin filer users/groups map to SIDs as well. So my bet is that your repeating SID is the BUILTIN\Adminstrators group. But really, you don't need to know what the SIDs map to. They all have corresponding user/group names - these are what are used for specifying permissions. And the AD guys set the permissions.
To continue on my story. finally I am able to get DC admin to come to my desk, and just enter his id and password. It works. However, I am getting following message. What following options should I choose?
CIFS - Logged in as email@example.com. The user that you specified has permission to create the filer's machine account in many (754) containers. Please choose the method that you want to use to specify the container that will hold this account.
(1) Create the filer's machine account in the "Computers" container (CN=Computers, Windows default) (2) Choose from the entire list (3) Choose from a subset of containers by specifying a search filter
Here is some background: Currently, we have CIFS running on an existing pair of filers, and we want to migrate CIFS to the new pair, then eventually retire the existingone. So, we need to keep all informaiton, including DC information. So, what should I do from here, should I choose (1), enter a new object under "computers" container, or choose (2)?
I don't know what (2) is, is this something that I may choose from for the existing pair of filers? I don't know too much about DC.The DC admin is not so sure about what I am asking. So, I once again turn to you for help!
This is a basic AD question - if the DC admin is not the same as the AD admin, maybe I understand him not knowing, and you should find the AD guy to see what OU he want's the account in. If the DC and AD admin is the same person, and he doesn't know what you're asking, I'd be a bit worried.
My understanding (disclaimer: I'm a unix guy, not an AD guy) is that it doesn't really matter where the machine account goes - but there may (should) be standards where they want ALL the machine accounts, and there may be different rules/permissions around those OUs. If all else fails, they can do a lookup on the existing controllers and put the new ones there.
It matters in the sense that group policy objects can be applied at the organization unit level. Delegation can also be handled at the OU level.
I would assume that you would want the new filer to be in the same OU as the existing filer so that the same policies get applied. So, just get the AD admin to check ADUC and see where the old filer is, and specify the same OU for the new one.
Unless you want it in another OU, in which case you'll need to sit down with the AD team and hash it out.
NetApp has some Professional Services Consultants that are very good at AD design, so it may be a good idea to talk to your SE about getting one of them involved in the decision making process.
I used (1) choice : (1) Create the filer's machine account in the "Computers" container (CN=Computers, Windows default)
then AD admin moved the new filer from "Computers" to the same container where the current filer located. Would that cause any issue, since he made change on AD side? Do I need to do anything on the filer to reflect the change?
The group policy of the exisiting filer on AD is empty. We have clikced the property on both new created and existing filer on AD, and made sure settings under "security" tab are all the same.
Also, in /etc/cifsconfig_share.cfg, there are a lot of commands similar to the following: "cifs shares -add Marketing... "
"cifs access "Market..."
Should "Marketing" here, for instance, be fefine somewhere in AD? Could you please tell me where exactly can I find these in AD?
You shouldn't have to do anything on the filer if you move the AD account to a new OU.
The cifs access commands use builtin and AD groups and accounts in ACLs. But in your example, "Marketing" is the name of the share - the line hasn't gotten to the ACL bit yet. The share names themselves are not a part of AD. You should see something like:
That S string is the SID, which maps to either an AD or builtin account. cifs lookup <SID> should tell you what it maps too. As for exactly where in AD to find the group or account, it could be in any OU - your AD admin would be able to help you.