I don't know whether removing Creator Owner from the ACL actually updates or changes the owner in any way. Probably need to test it, but the reason I took ownership back was to ensure that Administrators was always the owner.
No matter what the permissions on the folder above, a user creating a new folder always inherits the owner property and Creator Owner is bunged on the ACL. Unless I am missing something. But I have tested this and seen it happen. Maybe there is some custom permission I can apply on the folder above to avoid this, but the solution I have works fine and is pretty hands-off, so I'm not looking to change. For preserving (or not) permissions on file moves, I find robocopy is the way forward - although it's a long time since I had to move a lot of data about, so there's probably a much simpler option. On 28 April 2010 17:44, Ben Scott <[email protected]> wrote: > On Wed, Apr 28, 2010 at 11:54 AM, James Rankin <[email protected]> > 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/> ~ > -- "On two occasions...I have been asked, 'Pray, Mr Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
