As seen above, I have described in as much detail as to what we are seeing. The root folder in that shared directory is set up exactly like all others and no other shares are having any issues like this. Any sub folder that we create in the affected Share tree has permissions that state that they are inherited however the only thing for the Domain Admin Group selected is the "Special" and if you go into the advanced settings, it states full however it now becomes "This Folder Only".
Any sub folder beyond that has just Local Admin and System as the "Special" permissions. This is a relatively new issue and since it was originally created, this department's share has become quite large. Does anyone have any idea why it is occurring like this or should we just create a new subfolder for that group and move everything over? I would love to know the cause.
Any help would be appreciated. In 'Advanced Security' - if you double click one of the permissions that is not propagating down, you get the 'Permission Entry' properties form. If this box is ticked, it stops the permission propagating more than one layer down the tree. This overrides the 'Apply To This folder, subfolders.. As a result, on sub-folders, the 'Apply To' box sets itself to 'This folder' and greys itself out, and the permission in question doesn't inherit any further.
This kind of issue may occur if "Apply onto" and "inheritable permissions" are not correct or incorrect operations. I suggest you double check the "Apply onto" and "Allow inheritable permissions" to make sure they are configured correctly.
Meanwhile, you can create a new folder on E drive to test if the permissions can be inherited. If so, move the files from the problem folder to the new folder.
In addition, "cacls" command can collect a log file for research. Use the same method to collect a log to a folder which permission has been propagate successfully. Then, compare the two logs. I do not believe you provided an answer that was satasfactory so I unmarked your answer as the correct one. The root permissions are setup correctly as can be seen from the screen shots. You can also get an idea of the correct folder structure as shown by the cacls command. When you change it from This folder to This folder and Sub folders , does it retain the settings?
Also, you're stating "Share Permissions. Sometimes, if having issues such as this, it's easier to simply create another folder with the correct permissions and move not copy the items from the old to the new. Moving it will pickup the target's permissions. I cannot change it from This folder to This folder and sub folders. All options are greyed out like they were inherited. I'm sorry about that. You're completely correct that I'm using the wrong termonology. I do mean NTFS permissions.
This is a file within the folder within the share. Demo can access the share and access folder under share but cannot access files within the folder. Pretty much I am replicating the issue that users had.
They were able to open the file but only as Read-only access. From your 2nd screen shot the users will only be able to read and execute the data and not make any changes assuming they are accessing it through that share. I'm still not sure I understand the question, but if you expected permissions to be copied from your server to your server when you copied the folders, you need to use something like robocopy with the Security flag to copy permissions along with the files.
The issue was that permissions were inheriting down to the parent folder but child folders were recieving 'half permissions' in the sense that they would only have 'this folder only' once it reached the child folder.. This meant they could see files, but when they opened the files they displayed as Read-Only, they would also not be able to 'save-as' to the same file location as a work around.
After looking into the local groups then rooting these back through to the domain controller and domain groups. The users were all part of a security group that was no longer in use. This security group was completely vacant and removing seemed to allow users the required permissions.
During testing I found that giving the users domain admin rights allowed full access to the files even with this random group in tact, fully working now by leaving them as the required domain users, removing domain admins and the old vacant group.
To continue this discussion, please ask a new question. Spiceworks Help Desk. The help desk software for IT. Track users' IT needs, easily, and with only the features you need. Learn More ». Get answers from your peers along with millions of IT pros who visit Spiceworks. Very confused, if anyone could shed any light i would be very happy! This behavior cannot be caused by moving a folder when you are running a Windows Vista based computer.
The move operation now works because the folder or the file can inherit ACL of the target folder or file. The folder or file also has permissions that are marked as having been inherited from the parent. This behavior may be caused by moving a folder. When you move a folder, the ACL is not changed, and the inherited permissions are not updated.
Note that move in the context of this article always means to move within the same volume. When you move a file or folder, the ACL is also moved and is not changed in any way. Even when inheritance is enabled for this folder, the inherited permissions are not automatically updated. The ACL will be updated the next time you change permissions, and this forces the parent to propagate its permissions.
Setting the permissions of a parent folder by using an API that does not automatically propagate inheritance like Adssecurity.
0コメント