If I had to venture a guess, I would say that you've done a few things wrong there to get this behavior.
#1. When creating SMB shares, either do so from the CLI or when doing so from the WebUI Change the radio button from "Apply the Windows Default ACLs" to "Do Not Change existing permissions"
#2. ACLs always inherit, unless you on-purpose break inheritance that's their behavior, but the question is how you created the target parent directory. The recommended method when doing a data migration is always create the directories using the CLI meaning they will have POSIX permissions by default, therefore there won't be any ACLs to worry about inheriting.
#3. When doing an SMB migration to Isilon, on the source side you need local administrator and backup operator rights for the account doing the copy, on Isilon, use a special administrative share at the root of the access zone, that is administratively hidden, and give run-as-root permissions, only to the service account doing the copy. So if the data was stored at: /ifs/clustername/accesszonename/finance, I would create a share at /ifs/clustername/accesszonename as accesszonename$ and give the account you are using to do the copy say domain\username --run-as-root rights. Be really careful with this, but it'll give you what you likely need to get the data there intact.
#4. Something most people overlook until it bites them; Isilon does not support Historical SIDs, so if your source data has HSID values in the ACE entries for users or groups, you need to translate those during the migration or risk losing access. See KB88513 on support.emc.com. Use emcopy with /sidmapfile to remediate this.
#5. Evaluate if the source uses local users and groups in filesystem permissions. Like above we would always recommend using /sidmapfile with LOCALGROUPSID:NEWDOMAINGROUPSID to get rid of those old permissions when you migrate, and move to AD only permissions. This is critical long-term because if you were to simply move the groups to Isilon you would find that if you wanted to cutover to a DR site, those local groups wouldn't be there. This same issue comes up in NAS migrations from/to pretty much any NAS platform without the use of VDM/VFilers.
#6. Use emcopy, not robocopy. Emcopy is significantly faster than robocopy, especially if you have a large count of small files, or wide and shallow directory trees. In one example of 3 million 8KB files spread across 6 directories (in a tightly controlled lab), an incremental with Robocopy took 54 hours (server 2012 R2 version, default number of threads). Emcopy with the default number of threads did the same job in less than 90 minutes.
Beyond that there are commercial tools from EMC Select partners that certainly can help make the whole process easier, especially if it's a big migration.
Have a look at DataDynamics StorageX or Datadobi's DobiMiner N2N products. They can make your life much easier.
the robocopy /copyall copies the ACL so that's okay. im just wondering isnt it robocopy "SOURCE" "DESTINATION" ? in this case it seems to be the other way around?
please set the share permissions for the share you are copying on FULLACCESS you wont be able to change ACLs if the share has only modify permissions set.
#6. Use emcopy, not robocopy. Emcopy is significantly faster than robocopy, especially if you have a large count of small files, or wide and shallow directory trees. In one example of 3 million 8KB files spread across 6 directories (in a tightly controlled lab), an incremental with Robocopy took 54 hours (server 2012 R2 version, default number of threads). Emcopy with the default number of threads did the same job in less than 90 minutes.
Chris,
that is an unfair comparison. The default number of threads in emccopy (64) is higher than the default number of threads in robocopy (8). If you know your Tools and their parameters you can just modify the number of threads (robocopy: /MT:64 or higher..) and get (that's my guess and would be a fair comparison) the same performance.
That would be my recommendation: Use the tool you like more and where you know the parameters!
Appreciate all the replies, I am definitely going to check out all the suggested robocopy alternatives
What actually got it working for us in this instance was setting the user running the robocopy to "Run as Root" in the shares permissions, once that was done all the permissions came over perfectly.
EMC provided a very relevant doc which had the solution:
knowledgebase article 000089794 (how to configure an isilon cluster to use robocopy)
crklosterman
450 Posts
0
August 14th, 2015 02:00
Mugatu
If I had to venture a guess, I would say that you've done a few things wrong there to get this behavior.
#1. When creating SMB shares, either do so from the CLI or when doing so from the WebUI Change the radio button from "Apply the Windows Default ACLs" to "Do Not Change existing permissions"
#2. ACLs always inherit, unless you on-purpose break inheritance that's their behavior, but the question is how you created the target parent directory. The recommended method when doing a data migration is always create the directories using the CLI meaning they will have POSIX permissions by default, therefore there won't be any ACLs to worry about inheriting.
#3. When doing an SMB migration to Isilon, on the source side you need local administrator and backup operator rights for the account doing the copy, on Isilon, use a special administrative share at the root of the access zone, that is administratively hidden, and give run-as-root permissions, only to the service account doing the copy. So if the data was stored at: /ifs/clustername/accesszonename/finance, I would create a share at /ifs/clustername/accesszonename as accesszonename$ and give the account you are using to do the copy say domain\username --run-as-root rights. Be really careful with this, but it'll give you what you likely need to get the data there intact.
#4. Something most people overlook until it bites them; Isilon does not support Historical SIDs, so if your source data has HSID values in the ACE entries for users or groups, you need to translate those during the migration or risk losing access. See KB88513 on support.emc.com. Use emcopy with /sidmapfile to remediate this.
#5. Evaluate if the source uses local users and groups in filesystem permissions. Like above we would always recommend using /sidmapfile with LOCALGROUPSID:NEWDOMAINGROUPSID to get rid of those old permissions when you migrate, and move to AD only permissions. This is critical long-term because if you were to simply move the groups to Isilon you would find that if you wanted to cutover to a DR site, those local groups wouldn't be there. This same issue comes up in NAS migrations from/to pretty much any NAS platform without the use of VDM/VFilers.
#6. Use emcopy, not robocopy. Emcopy is significantly faster than robocopy, especially if you have a large count of small files, or wide and shallow directory trees. In one example of 3 million 8KB files spread across 6 directories (in a tightly controlled lab), an incremental with Robocopy took 54 hours (server 2012 R2 version, default number of threads). Emcopy with the default number of threads did the same job in less than 90 minutes.
Beyond that there are commercial tools from EMC Select partners that certainly can help make the whole process easier, especially if it's a big migration.
Have a look at DataDynamics StorageX or Datadobi's DobiMiner N2N products. They can make your life much easier.
Hope this helps,
~Chris Klosterman
Advisory Solution Architect
EMC Isilon Offer & Enablement Team
chris.klosterman@emc.com
twitter: @croaking
Stdekart
104 Posts
0
August 12th, 2015 13:00
Mugatu,
Is there an application your using to transfer the files, or simply using "copy" on cmd through windows?
Where are the files being copied to on the Isilon cluster?
Can you get the following info around the path/share (I'm assuming SMB is being used):
# ls -led
and also
# isi smb shares view --share=
umichklewis
3 Apprentice
•
1.2K Posts
0
August 12th, 2015 14:00
What application are you using to move your data? EMCOPY? Robocopy? What flag(s) are you using?
Mugatu1
3 Posts
0
August 13th, 2015 07:00
hi, we are using robocopy to bring the files across
EX: robocopy "\\njpisilon1\dept02" "c:" 05audi /e /z /copyall /np /V /r:2 /w:1 /XO /FFT
here is the ls output:
njpisilon1-2# ls -led dept02
drwxrwxr-x + 5 root wheel 76 Aug 12 21:49 dept02
OWNER: user:root
GROUP: group:wheel
CONTROL:dacl_auto_inherited,dacl_protected
0: group:Administrators allow dir_gen_all,object_inherit,container_inherit
1: creator_owner allow dir_gen_all,object_inherit,container_inherit,inherit_only
2: everyone allow dir_gen_read,dir_gen_execute
3: group:Users allow dir_gen_read,dir_gen_execute,object_inherit,container_inherit
4: group:Users allow std_synchronize,add_file,add_subdir,container_inherit
isi output:
njpisilon1-2# isi smb shares view dept02
Share Name: dept02
Path: /ifs/DepartmentShares/dept02
Description: Dept shares
Client-side Caching Policy: manual
Automatically expand user names or domain names: False
Automatically create home directories for users: False
Browsable: True
Permissions:
Account Account Type Run as Root Permission Type Permission
------------------------------------------------------------
Everyone wellknown False allow change
------------------------------------------------------------
Total: 1
Access Based Enumeration: No
Access Based Enumeration Root Only: No
Allow Delete Readonly: No
Allow Execute Always: No
Change Notify: all
Create Permissions: default acl
Directory Create Mask: 0700
Directory Create Mode: 0000
File Create Mask: 0700
File Create Mode: 0100
Hide Dot Files: No
Host ACL: -
Impersonate Guest: never
Impersonate User:
Mangle Byte Start: 0XED00
Mangle Map: 0x01-0x1F:-1, 0x22:-1, 0x2A:-1, 0x3A:-1, 0x3C:-1, 0x3E:-1, 0x3F:-1, 0x5C:-1
Ntfs ACL Support: Yes
Oplocks: Yes
Strict Flush: Yes
Strict Locking: No
sluetze
2 Intern
•
300 Posts
0
August 14th, 2015 01:00
the robocopy /copyall copies the ACL so that's okay. im just wondering isnt it robocopy "SOURCE" "DESTINATION" ? in this case it seems to be the other way around?
please set the share permissions for the share you are copying on FULLACCESS you wont be able to change ACLs if the share has only modify permissions set.
Rgs
Steffen
sluetze
2 Intern
•
300 Posts
0
August 14th, 2015 02:00
Chris,
that is an unfair comparison. The default number of threads in emccopy (64) is higher than the default number of threads in robocopy (8). If you know your Tools and their parameters you can just modify the number of threads (robocopy: /MT:64 or higher..) and get (that's my guess and would be a fair comparison) the same performance.
That would be my recommendation: Use the tool you like more and where you know the parameters!
Rgs
Steffen
Mugatu1
3 Posts
0
August 14th, 2015 06:00
Appreciate all the replies, I am definitely going to check out all the suggested robocopy alternatives
What actually got it working for us in this instance was setting the user running the robocopy to "Run as Root" in the shares permissions, once that was done all the permissions came over perfectly.
EMC provided a very relevant doc which had the solution:
knowledgebase article 000089794 (how to configure an isilon cluster to use robocopy)