The values you want are HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Fo rceCopyAclwithFile HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Mo veSecurityAttributes
This KB details this: http://support.microsoft.com/kb/310316 -----Original Message----- From: Mayo, Bill [mailto:bem...@pittcountync.gov] Sent: Wednesday, April 28, 2010 12:08 PM To: NT System Admin Issues Subject: RE: The finer points of NTFS ACLs (was: Software installs on new PCs) +infinity We do exactly what you describe, and I always have issues (mostly when doing file migrations due to server moves) related to people copying files from one secured directory to another and the permissions not getting updated. When the permissions are set to inherit from parent, it seems to me that Windows should re-assess that on a file copy. Bill Mayo -----Original Message----- From: Ben Scott [mailto:mailvor...@gmail.com] Sent: Wednesday, April 28, 2010 12:45 PM To: NT System Admin Issues Subject: The finer points of NTFS ACLs (was: Software installs on new PCs) On Wed, Apr 28, 2010 at 11:54 AM, James Rankin <kz2...@googlemail.com> wrote: > We see this problem where people create folders under shared drives, > that each new folder is owned by the creating user who then has the added rights. > The solution is some weekly subinacl tasks that re-take ownership of > the whole fileserver structure back to BUILTIN\Administrators Wouldn't it be better to just remove "CREATOR OWNER" from the ACL on the folder? All our shared folders are set so only the group(s) which should have permission are present. The only good use for "CREATOR OWNER" I've found is kludging around apps that insist on writing to their own program directory. So grant users "Create File" on "This folder only", and separately grant "CREATOR OWNER" "Modify" on "Files only". Now users can create the file, but can't touch anything else. My biggest beef is that if you move an object within a "drive" on Windows, Windows does not update the ACL on the object to reflect different permissions in its new location. So, for example, when a file is moved from the QA-only pre-release folder to the whole-company general-release folder, the file still has permissions for pre-release and nobody else can read it. Anyone got a fix for *that*? -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
