Thank you everyone for the responses.
The core problem we're trying to address is how to map Unix permission mode bits to NTFS ACLs. The Celerra's NATIVE access-checking policy keeps separate Unix and NTFS permissions, so even if there is a Unix->Windows account mapping in place and NTFS ACLs on a file structure, Unix users accessing NFS exports use Unix security instead.
On a NetApp qtree with NTFS security, on the other hand, there are no Unix permissions--only NTFS ACLs. Therefore, we need to replicate the old Unix permissions as equivalent NTFS ACLs.
For example, we have a user oracle@unix with data on Celerra accessed via NFS. The same data is also accessed by AD users via CIFS. The Celerra's NATIVE access-checking policy maintains 1) Unix mode bits for oracle's UID/GID and 2) NTFS ACLs for AD users. As I understand it, even if there is an "oracle" user in AD, the AD account is not used for file access-checking via NFS when oracle@unix accesses the data.
Here are a few additional points of clarification on our environment:
- We want to avoid ONTAP's mixed security style if at all possible.
- We are using NTFS security style on all Volumes/Qtrees with mixed NFS/CIFS data.
- We have LDAP configured so Unix users either are, or can be, mapped to AD users.
This is the migration process we've settled on:
- Set volume/qtree security style to Unix
- Rsync all data from Celerra export to corresponding NetApp export via NFS (rsync -a to preserve all permissions, times, etc.)
- Set volume/qtree security style to NTFS
- Perform incremental update, including ACL updates on ALL files, using Windows migration tool and CIFS.
Following step 2 above, Unix hosts see normal Unix permissions on the destination (NetApp) NFS export. These permissions mirror the original copy
on the source as you would expect (e.g "rwxr-x---".
Following step 3 above, there is no change in the Unix permissions
Following step 4 above, Unix hosts see either NO permissions ("---------") or ALL permissions ("rwxrwxrwx") depending on whether the Unix user is not mapped or is mapped to an AD account. Neither of these are desirable, as we'd like the Unix user to see something more closely approximating the original Unix permissions.
So, if it's relatively straightforward to generate Windows ACLs from Unix mode bits, then that's what we need.