bulk NFTS folder permission
-
Friday, June 22, 2012 9:15 PM
i have a file structure with 1.2 million files and 5,000 folders. this structure is duplicated in a non-production environment, and every couple of months we refresh that non-prod environment with the data from prod, and the process overwrites all the non-production folder permissions with production permissions, and we have to reset them to the non-prod permissions.
to be more accurate, it doesn't "overwrite" the folder permissions, because basically we are taking a snapshot of prod, mounting it to the non-prod server, and then sharing out the new mount with the same share name it was before the refresh. so it "replaces" the folder permissions.
luckily the vast majority of the 5,000 folders are inheriting from their parent folders. there are only maybe 15-20 places we need to make changes (where inheritance isn't turned off), but so far it's still been a tedious manual process because we have to wait for each change to propagate down to thousands of files. i'd like to have a script or a batch file i can just kick off after the new mount is complete, and trust that it'll be finished in the morning.
i was been experimenting with icacls, but then i started thinking about powershell. if i kept the "old" mount mounted while i also mounted the "new" mount, in theory i could basically do a recursive get-acl on the whole directory c:\mounts\oldmount and just pass that to a set-acl on c:\mounts\newmount.
in theory.
my concern is that a get-childitem c:\mounts\oldmount | get-acl is going to (try to) load the acls of over a million individual files into memory, right? that's probably not going to work, is it? particularly if the non-prod machine is a not-so-beefy vm... so what's a good strategy for easily resetting permissions on a structure with so many *files,* even if i'll only really touch a relatively small number of *folders," while letting inheritance take care of the rest?
All Replies
-
Friday, June 22, 2012 9:50 PM
Use RoboCopy and set it to not overwrite permissions. It can then refresh all of the files and not change any permissions.
¯\_(ツ)_/¯
- Proposed As Answer by BigteddyMicrosoft Community Contributor Saturday, June 23, 2012 6:22 AM
- Marked As Answer by IamMredMicrosoft Employee, Owner Monday, June 25, 2012 2:28 AM
- Unmarked As Answer by John_Curtiss Monday, June 25, 2012 2:46 AM
- Unproposed As Answer by John_Curtiss Monday, June 25, 2012 5:55 PM
-
Monday, June 25, 2012 6:14 PM
i'm not copying any files from ServerProd to ServerQA. i'm taking a snap of serverProd and mounting it to ServerQA. so nothing is getting "overwritten." copying the data over the wire has been ruled out as an option. the process is creating a brand new folder structure on ServerQA with the permissions from ServerProd. i need to change the permissions.
-
Monday, June 25, 2012 6:19 PM
i'm not copying any files from ServerProd to ServerQA. i'm taking a snap of serverProd and mounting it to ServerQA. so nothing is getting "overwritten." copying the data over the wire has been ruled out as an option. the process is creating a brand new folder structure on ServerQA with the permissions from ServerProd. i need to change the permissions.
Can you explain what you mean by taking a snapshot? If it is a snapshot why do you need to create folders?
¯\_(ツ)_/¯
-
Monday, June 25, 2012 8:15 PM
serverprod and serverQA are both connected to a SAN.
serverprod has d:\application\folder1\subfolder. the d drive is on the san.
i take a snap/clone/replica of serverprod's D drive with the san software.
i mount that to serverqa with the san software, where it appears as c:\mounts\ddrive\application\folder1\subfolder.
this is way faster than moving the application directory from one server to another with SMB, so we don't have to keep production users out of the production application as long. there are also other supporting servers (ie SQL) refreshed this same way.
the Application folder is shared out as \\serverqa\application. this is so Application's QA testers can test Application in an environment that more accurately duplicates production conditions.
the Everyone group has Change rights on the share. but production accounts/groups now have NTFS permissions on serverqa's \application\folder1\subfolder. i change the permissions on all these folders so QA accounts/groups have permissions and production accounts/groups don't.
at this point everything is good and set the "QA way." two months from now this process is going to repeat and i'm going to have to reset the permissions again. and remember there are ~5,000 folders and ~1.2 million files under \application. there are also two other non-production environments that periodically get refreshed this same way from serverProd, and we have to reset the permissions on those when it happens i'm looking for a good way to quickly, or at least easily, apply the "QA way" back to all these folders.
-
Monday, June 25, 2012 8:34 PM
Ther eis actually a much easier way to do that.
Use Nested Groups.
Place groups on the two parallel folder sets that model the access rights. One for read, one for modify and one for full and any other special cuts. These groups are dedicatied to the two folder structures and each folder structure has its own set of groups.
Now just swap the group membership (change the groups that are nested within the permisions groups as needed to add or swap access). This can be very quickly done is a small script. Tis is how I have done this exact sort of thing for many years. It is one area wher eWIndows security makes life very easy fo rupdating access without constantly resetting the permissions. Sometimes it takes a little head scratching to see the best approroach but I have not yet found a situation where this approach could not be made to work.,
¯\_(ツ)_/¯
- Edited by jrvMicrosoft Community Contributor Monday, June 25, 2012 8:37 PM
-
Monday, June 25, 2012 8:51 PM
hmmm... so i would need to set the folder permissions using local server groups with identical names (serverprod\write, serverqa\read) , and then put domain groups into those local groups. if i used AD groups for the permissions, the top level group would always get changed to the Prod group.
-
Monday, June 25, 2012 9:17 PM
would folder permissions granted to serverprod\MyGroup even translate correctly to serverqa\MyGroup? or would i just have some random SID in the ACL on serverqa?
actually now that i think about it, it's not that simple; "ADQAGroup" doesn't necessarily have exactly the same permissions on ServerQA that "ADProdGroup" has on ServerProd. and again we're talking about four environments with various differences. what stays constant are the permissions in each environment between refreshes.
i think i need to reset the permissions.
-
Monday, June 25, 2012 9:25 PM
i just created a group on serverprod named Group1 and a group on serverqa named group1. i created a blank test file named test.txt on serverprod and gave group1 read access to it. i copied the file to serverqa, and (as expected) Group1 isn't in the ACL anymore. can you give me details on how you're getting this to work?
-
Monday, June 25, 2012 9:29 PM
A reprise of earlier views:
It may take a bit of hard thinking but it can be done. The applied groups woul d be local. Just change the contents of each group. Domains don't matter if the target groups would have been directly added.
Think hard about this and save yourself a whole bunch of headaches.
What you do NOT want to do is repeatedly overwrite all DACLs. It is a formula for disaster which will likely explode when you can least afford.
Nested groups were invented to allow for just this kind of scenario. It is often a question on admin cert exams. I had at least a dozen variations on this theme on my first MCSE exams.
¯\_(ツ)_/¯
-
Monday, June 25, 2012 9:33 PM
i just created a group on serverprod named Group1 and a group on serverqa named group1. i created a blank test file named test.txt on serverprod and gave group1 read access to it. i copied the file to serverqa, and (as expected) Group1 isn't in the ACL anymore. can you give me details on how you're getting this to work?
Sorry but I don't think you understand. The files cannot have each file with highly individualized security settings to a user. This iwould be a completely insane way to design your security. Files get teh security from the folder. You are trying to tell use you are not moving the files but are taking some kind of a snapshot that soes not create a copy of a file - a good thing to ba able to do on WINdows if you can -
Files can be copied via RoboCopy without carring a copy of originating security . The target folders will control the access. Any other scenario is going to be impossible to control.
¯\_(ツ)_/¯
-
Monday, June 25, 2012 10:03 PM
i wouldn't be setting permissions on individual files in production. this was a test to see if/how permissions on a local group would transfer from server to server, which they did not.
what i'm understanding you to say is that if i have serverProd\Localgroup1, which has domain\ADGroupProd as a member and has read access to the serverprod\application folder, that when i mount the serverProd\Application folder to ServerQA, somehow "localgroup1" will still have access to the Application folder, and i just have to remove domain\ADGroupProd from localgroup1 on serverQA and add domain\ADGroupQA to give domain\ADGroupQA rights to the serverQA\application folder.
except, from my test, the application folder will keep zero knowledge of localgroup1 when it gets moved from oen server to another, so changing the membership of localgroup1 on serverQA won't help me.
am i misunderstanding? is your nested groups solution dependent on robocopy? but i thought if i was using robocopy the folders would keep their permissions, so why would i need to mess with the groups at all?
-
Monday, June 25, 2012 10:14 PM
Aha! NOw you are changing the rule.
If you mount a folder (file service) to a DFS share it does not exist on theat share. It is not a copy it is the real thing. Just cahnge the underlying folders permssions or change the shares permissions. Change the permisisons by cahnging the group membership. Wher this is mounted has nothing to so with the permissions.
Global DFS share: \\domain\share1
I mount \\server1\local1 to teh FS share service. It just exeists there The permisisons are what they are.
If I have a goupt on \\server1\loca11 that is Local1Modify and it has test grpooups then test can acecess the files. If I remove the test groups from Local1Modify and add th eproduction grous to Local1Modify I will have changed the access without changing any DACLs on anything.
¯\_(ツ)_/¯
-
Monday, June 25, 2012 11:10 PM
no. there's no DFS. there's two separate servers, two separate shares, two separate environments. at no point will a group from one environment need to touch the data in the other environment. at no point will one share point to a server in another environment.
today, i have a share called \\serverprod\application. it lives on a server called serverprod, on the D drive, in a folder called "application." a domain group called ADGroupProd has NTFS Read access to the d:\application folder.
i also have a share called \\serverQA\application. it lives on a server named serverQA, in a folder called c:\mounts\Ddrive\application. a domain group called ADGroupQA has NTFS read access to c:\mounts\ddrive\application. it has these permissions because i manually set them after the last refresh.
tonight, i'm going to "refresh" serverQA again, with data from serverProd.
at the beginning of the refresh process, c:\mounts\Ddrive\application gets destroyed on serverQA. gone. no folders remain, so no folder permissions remain. this is because "ddrive" is really an entirely separate 300GB hard disk (visible in Disk Management) *mounted* by the SAN software, but it appears to windows as just another folder under c:\mounts. i unmount "Ddrive" at the beginning of the refresh.
after the refresh process, i will have a brand new c:\mounts\ddrive\application folder on serverQA. it will have the exact same NTFS folder permissions as d:\application on serverProd. because "ddrive"is really a brand new 300GB disk that is an exact clone of serverProd's D Drive. it just appears to windows as another folder under c:\mounts. that is to say, ADGroupProd will now have read access to both \\serverProd\application and \\serverQA\Application, while ADGroupQA has no rights to either.
i need to reset the permissions on c:\mounts\ddrive\application on serverQA so that ADGroupQA has read rights instead of ADGroupProd. ServerProd is not going anywhere and ADGroupProd needs to keep its access to \\ServerProd\application (d:\application on serverprod).
can your nested groups help me?
-
Monday, June 25, 2012 11:24 PM
Just change the contents of the group after you mount the drive or before. It doesn't matter. I do not know how to make it any clearer. The groups exists independent of any mounted file system. The Group membership can be changed and the file access will be controlled by whatever the contents of the group is at the time of access.
I think I am going to back off on this becuse I don't think you understand what I am trying to say and I cannot think of an easier way to say it. Perhaps someone else can explain it better.
¯\_(ツ)_/¯
-
Monday, June 25, 2012 11:35 PM
one last time:
so if on d:\application on serverprod, i give read rights to a local group named "localgroup1," and make ADGroupProd a member of localgroup1, you're saying that after i mount ddrive\application to ServerQA, that the ACL of the Application folder will still grant read rights to "localgroup1," and all i need to do is change the membership of localgroup1 on serverQA?
-
Monday, June 25, 2012 11:45 PM
Why wouldn't it? The definition exisits external to teh drive. The DQCL contains the SID of the group an that is all. YHe contents of teh grouyp get access throught the group SID. That is how NTFS permissions work. If you clsely inspect the DACL you wil only ever see teh SID of the group in th DACL. The memnbeship of the group never is visible. Thi si swhat makes NTFS security superior to many earlier systems that used the group as s ource to apply to the folder security. In many legacy systems the SDs did not reside on tehg physical media. In NT the SD is part of the directory entry and metadata of the stored object. Just like a database. It was designed this way on purpose and was designed this way just so we could do this exact thing.
¯\_(ツ)_/¯
-
Tuesday, June 26, 2012 12:17 AM
ok good, i do understand you.
i suppose my skepticism/confusion is because of just what you said: the SID. if we are using a local group on serverprod named localgroup1, even if the SID for that group comes over to serverQA in the ACL for the Application folder, and even if serverQA has a group called localgroup1, will that localgroup1 have the same SID as the serverprod group by the same name? if not, what good will the sid from serverprod do us in the ACL? it's not that i don't believe you, i just haven't seen it before and i'm confused how the sid from a local group on one server could be used by a separate server.
how can i play around with this on a small scale and without involving my san guy and a full-blown refresh? robocopy a few folders with a switch to maintain the permissions on the source folders?
-
Tuesday, June 26, 2012 12:29 AM
The SID belongs to the server it is defined on. You cannot use a local SID from a foreign servers except if it is a reference to the SID.
You say “comes over”. Nothing comes over on a mount. The remote files are mounted to the share. The group has to be local to the server it is mounted to or it has to be a domain SID (Group).
¯\_(ツ)_/¯
-
Tuesday, June 26, 2012 1:36 AM
i feel like i've asked several times if you're saying to use groups local to the server, and you've said yes every time, until the last time, and now you're telling me i have to use a domain group, for the exact reason i doubted i would be able to use a local group.
i understand that i if i use domain groups, the permission can be granted on multiple servers.
but i can't use domain groups. because the group that needs access to serverprod.domain.com\application will never need access to serverqa.domain.com\application. so i can't just swap out members of domain groups. it wouldn't work. no matter what group i give access to d:\application on the Production server, *that* group is going to have rights to the QA server after the refresh. and i can't just add/remove/swap out members of that group, because it still needs access to the production server. the prod group will always have access to the prod server. it will never not need access to the prod server. so it can never be used to grant access to the qa server.
You: "use nested groups."
me: "local server groups?"
you: "The applied groups would be local. Just change the contents of each group."me: would folder permissions granted to serverprod\MyGroup even translate correctly to serverqa\MyGroup?
or would i just have some random SID in the ACL on serverqa?me: when i mount the serverProd\Application folder to ServerQA, somehow "localgroup1" will still have access to the Application folder?
me: so if i give read rights to a local group named "localgroup1," you're saying that after i mount ddrive\application to ServerQA, that the ACL of the Application folder will still grant read rights to "localgroup1?"
you: "why wouldn't it? The definition exisits external to teh drive."
me: what good will the sid from serverprod do us in the ACL? i'm confused how a sid from a local group on one server can be used on another server.
you: "You cannot use a local SID from a foreign servers. The group has to be local to the server it is mounted to or it has to be a domain SID (Group)."
you: "I cannot think of an easier way to say it. Perhaps someone else can explain it better."
i feel like i'm being punked. this thread derailed back when my imaginary DFS came into play. thanks for your time.
- Edited by John_Curtiss Tuesday, June 26, 2012 1:39 AM
-
Tuesday, June 26, 2012 1:36 AM dude, just use icacls.exe!
- Marked As Answer by John_Curtiss Tuesday, June 26, 2012 1:37 AM
-
Tuesday, June 26, 2012 2:22 AM
Sorry but i Guess you do not understand what I am saying. Sorry I can't explain it better. Unfortun;ately what you are saying about your setup s not very consistent.
Just do whatever you think works.
¯\_(ツ)_/¯
.png)
