NTFS grey tick

Ok... heres the scenario.

We have a departmental share. \\server\share.

Within that each team has their own directory which DOES NOT inherit the root permissions of the share. Each teams directory should have an ACL specific to the team. Some of the teams directory ACL's have not been set correctly.

Our teams directory was set to just limit access to us and our IT support. Unfortunately one of our users managed to drag it into another teams directory. It was located, and moved back to the root of the share.

However, I just checked the NTFS on our directory ACL and its not what it was before.


question 1 - if you move directory purposely or unintentionally from root of a share, to inside another teams directory, then move it back. Does it scoop up the ACL from within that other teams ACL. As thats what seems to of happened.

question 2- what does a grey tick next to an NTFS ACL option represent. For example, our group has solid black ticks next to the various NTFS options, but theres another group on their, with a grey faded tick next to the NTFS ACL options. Just wondered if thats relevant.
Who is Participating?
Brian PierceConnect With a Mentor PhotographerCommented:
A grey tick means that the permission is inherited from the parent object, eg the folder in which the file sits.

NTFS file and folder permissions always follow these rules when file/folders are moved

If a new version of the file/folder is created then the new objects always inherit the permissions of the new parent folder.

If you therefore COPY a file from one folder to another, by definition a new copy is created so the new object inherits the permissions of the new parent folder.

If you MOVE a file across partitions, it is essentially copies and then deletes the original, so again new object inherits the permissions of the new parent folder.

The only exception is if you MOVE a file/folder within the SAME PARTITION, when NTFS does not do a copy - it simply changes the file pointers which indicate which folder the file is in. in such a case the moved file/folder KEEPS its original permissions.
pma111Author Commented:
question 3 - how can I identify which users had permissions in the other directory where our directory ended up to copy it there, even if it was unintentional. That may help limit who actually did it.
pma111Author Commented:
Thanks KCTS - I am not sure on the "transfer mechanism", be it by a copy or a move.

But whether it be a copy or a move, if I wanted to copy \\server\share\dir to within \\server\share\dir2 I'd need write(?) permissions to either copy or move that file into that location wouldnt I?

Just trying to tie down who moved our folder via seeing on that ACL who could have done so.
pma111Author Commented:
PS _ it was moved on the same partition not onto a different one. What I wondered though is if its moved to a sub dir, those on the parent directory, if they have full control - cant they just apply the parent permissions to anything in its child folders - this wiping out all the more restrictive child permissions? I assume if they didnt have full control they could do this, but if they did they could.

So if moved from A to B on the same volume, B has very open ACL, but as A was moved on the same volume, just as users can access \\server\share\B doesnt automatically mean they can access \\server\share\B\A
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.