Sorry about the delay in responding to this query. First thing first, I'd like to clarify for the MIXED qtrees, you don't need to set the "MIXED" style just because the users are trying to access their files from UNIX and Windows both sides. You need MIXED only in the case you'd need to manage and change the permissions from both sides.
I'd still recommend not to set it to MIXED, unless you really have a pressing need and/or you fully understand how to manage the MIXED security style environments.
1. If possible, within the MIXED style filesystem, isolate the folders which are mostly going to be accessed and managed from the Windows users and set the NTFS ACLs for them. Similarly any other folders which are going to be heavily accessed and managed by the UNIX users, then set the permissions to be the UNIX permissions.
2. If the users are changing the permissions from Windows side at one time and changing it from UNIX side at another time... NetApp filers are going to keep only one set of the permissions active at any given time. e.g., if some UNIX user is trying to access the filesystem and there are NTFS ACLs active at that point, filers compute the UNIX mode bits based on the currently active NTFS permissions and offer that to the UNIX user and vice-versa.
For the details on understanding, how the multiprotocol really works with NetApp systems, I'd recommend the TR-3490.
For your first two question on the permissions for the CIFS shares, you don't need to use the UNIX style RW or RO permissions, those are generally used for the UNIX groups. You can very well use the full control, change, read type of the CIFS share level permissions for the Windows AD groups. After that you can restrict further with more granular permissions at the folder level using the NTFS ACLs.
For home dirs, I'd suggest to check the admin guides on the NOW site for the complete configuration, as you don't need to create one share per user's homedir. You just need to share out the higher level homedir container (volume or qtree) and then create the users' dir underneath and set the individual NTFS ACLs and ownership for each user on their respective folders using Windows Explorer.
I hope I answered all your questions, let me know if still any.
Thank you very much for the descriptive explanation. It cleared few of my doubts. I am still left with few more questions.
For your first two question on the permissions for the CIFS shares, you don't need to use the UNIX style RW or RO permissions, those are generally used for the UNIX groups. You can very well use the full control, change, read type of the
CIFS share level permissions for the Windows AD groups. After that you can restrict further with more granular permissions at the folder level using the NTFS ACLs.
1. Well, sorry for the confusion; When I mentioned RW/RO, I actually meant setting some permissions (not exactly Unix style perms). Back to my questions on CIFS share level permissions:
How can we set "CIFS share level permissions based on windows AD groups" on the Netapp filer? I tried a test command, but looks like it was expecting local unix group. Please fill me in
ls -l /mnt/filer/testuser/file1(A file present under the root folder) ---------- 1 testuser staff 600 2009-08-31 10:54 /mnt/filer/testuser/file1 (Edits to this file from NFS client are denied as expected from perms)
From CIFS client (Mac machine)
ls -ld /mnt/filer/testuser drwxrwxrwx+ 1 testuser DOMAIN\domain users 16384 Nov 6 18:43 /mnt/filer/testuser
ls -l /mnt/filer/testuser/file1 -rwxrwxrwx+ 1 testuser DOMAIN\domain users 600 Aug 31 10:54 /mnt/bang/file1(Edits to this file from CIFS client are also denied but the perms look very confusing)
3. In the example scenario mentioned in the above point, if we were to set NTFS ACLs (owner - full control) on a Home directory by logging in as a "Domain Admin" in a Windows server (which is in the domain), I would assume in this case that filer computes the Unix permissions as well (based on the NTFS ACLs). But, I tested for few directories. The Unix permissions were just shown as "root:daemon" (for owner:group) and 700, though the individual owners have "Full control" on their respective home directories.
Am I doing something wrong? If yes, what is the proper way to set the ownership and perms on a Home directory?
Based on my testing: a. If we set the Unix permissions, they weren't looking consistent when accessed via CIFS.
b. If we set the NTFS ACLs, they weren't looking consistent when accessed via NFS.
For # 1, you are using the "-g" switch which is used mostly for the unix groups. For giving access to the Windows groups, you can just specify the domain\groupname and the type of access with it.
For #2 & #3, what you are seeing is just the display of the permissions like that, actually I have generally seen it showing correctly. Some possible issues I can think of, if you don't have that user account existing on the other side... also check if there's any /etc/passwd file on the filer as well, generally you should keep one.
How about actually testing the access with these homedirs ? Does it work fine as expected ? Also any specific reason why you wanted to choose MIXED for your homedir containers ?
#1: Thanks, I was able to modify share permissions based on AD group(s).
#2 & #3:
> if you don't have that user account existing on the other side
All the machines (including the filer) are part of the domain. And users login with only their respective domain accounts. So, this must not have been the case.
> /etc/passwd file on the filer
Yes, this exists on the filer. Any other thoughts on what might be going on??
Mixed mode qtree: Lot of our users access and modify files/folders from various operating systems (windows, linux and mac).
Testing the home directories: We have actually migrated home directories for few users and asked them to test the same. Our observations are mentioned below. So we are stuck at this place.
1. When we set the NTFS permissions on a home directory (from a windows server present in the domain): The user is able to access the home directory (and containing folders) properly from windows clients. But, from Linux clients using NFS, users get "permission denied" errors - this could be because the "Unix perms" are always "root:daemon".
2. When we set the Unix permissions on a home directory (from a windows server present in the domain using secure share s/w): The user is able to access the home directory (and containing folders) properly from Linux clients using NFS. But, users get "access denied" errors when accessed from windows clients.
One more quick question: Is there any way to see the effective latest (NTFS/Unix) permissions of a file / folder that is residing on a mixed mode qtree from the filer? I thought it would be really helpful while troubleshooting issues if this was possible.
My other thoughts are if somehow that UNIX username is not existing on the UNIX side or Windows AD account not existing on the AD side or somehow these accounts are not mapping to each other.
BTW the TR3490, not sure if you have gone thru it, gives you a good understanding of the multiprotocol access. You can check couple of things, else I'd recommend to open a support case with NetApp, as if needs to be troubleshooted completely with the data from your systems.
Check if you are using NIS for unix user authentication, if not, put the unix user in the local /etc/passwd file of the filer. Make sure to update the order for passwd in the /etc/nsswitch.conf file accordingly.
Make sure the UNIX and Windows user names are mapping to each other correctly by looking at the "wcc -s <windowsusername>" and "wcc -u <unixusername>".
If these are the same names, then the filer would do an automatic mapping, if not, you may need to set an explicit mapping in the /etc/usermap.cfg file.
Ensure that the users are in the appropriate groups on UNIX or Windows side which show up on the permissions list.
You can use the "fsecurity" CLI tool on the console to see the complete security descriptor of any file/folder object. That should help you a lot.
Also there's another CLI tool for troubleshooting the access problems, called "sectrace". You can create a filter for any specific user or the path for which you want to trace the access and see why you get permission denied or approved access.
I hope you could fix your issue within these steps.