• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 755
  • Last Modified:

Users can read shares, but not write. Permissions look ok.

This is a really strange issue. It seems as if all accounts except for Domain Admins cannot write to the domain controller. It happens that the file sharing is done by the domain controller.

When I check for Effective Permissions, it looks good, in otherwords the user can read/write/delete and in some cases the user is the owner of the directory.

Since these issues seem to be only on this domain controller my thoughts are that it has to have something to do with the security settings on this machine, or the local security policy. What should I check to ensure that users can write to shares on the domain controller?

1 Solution
Darryl AllenCommented:
Are you setting the permissions for the directory itself, or are you setting them in the "Sharing" permissions?
What permissions are you looking at? NTFS permissions on the file system, or at the share permissions. The most restrictive permissions of NTFS & share permissions takes effect.

Personally I set all my shares to Administrators: Full control, Authenticated Users: Change. Then control all permissions via NTFS. NTFS affect people logged in locally as well as people accessing stuff over the network, but share permissions only affect people accessing the shares.
As the two above have said, i'd check the share permissions which are by default read only. You will probably find these are restricting the access the user has.
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

edowningAuthor Commented:
The share and NTFS perms are good. They have been good for awhile. Trust me on that. It is set up exactly as you have described. I have hunted down permissions errors (share level and NTFS) for four hours now and I am 99.99% confident it has nothing to do with NTFS and share level permission settings.
edowningAuthor Commented:
Let me just stop the train of NTFS and share level permission settings comments that I'm sure is coming. I've quadruple checked my NTFS and share level permission settings. They are as they should be.

share level: Domain users=Full Admins=Full
NTFS: According to user group

This has something to do with the local security settings or a bad GPO on the DC OU. Please think about what could be causing this issue in relation to those factors, not share or NTFS permissions.

Thank you =)
edowningAuthor Commented:
Update: I created a new share on the server with the above mentioned settings and same issue. User can read & create, but not modify or delete. I even gave the everyone account full control on both NTFS and share - same deal.

I've been going through the local security policy and GPOs however nothing "seems" amiss so far.

I'm out of ideas. What fundamental thing am I missing?
edowningAuthor Commented:
UPDATE: well, I created shares on all the servers with the above perms and still the same issue, so it's not just limited to that domain controller. Perhaps something gone wrong in the security channel? I don't get it.
I've never seen anything like that... at least that couldn't be fixed by proper NTFS/share permissions which you seem to have ruled out with Full Control/Full Control.

I'm pretty familiar with GPO's and routinely apply massive ones to comply with DoD standards, but am not familiar with anything that would cause the ability to read/create files, but inability to modify them.

By security channel, you mean stuff like Microsoft Network Server/Client:sign/encrypt network traffic under Security Settings > Local Policies > Security Options? I've messed with those a lot & broken things because of it, but never like that. Those settings lead to an all or nothing communications problems where a server or workstation can't talk to another box at all.

Are you familiar with the RSOP (Resultant Set Of Policy) MMC snapin? It will show you the results of all GPO's and local policies applied to a box rather than looking at things individually. You may find some anomalies that way.
edowningAuthor Commented:
I installed a TrendMicro A/V solution and inadvertently turned on it's "Behavior Monitoring" feature for network shares. Ugh. Uninstalled and life is good again. Except for my headache. That's still there.

although you have checked permissions for the users, try checking for permissions that apply to other groups as DENY always overrides ALLOW.

EG, user many also be part of 'domain users' group and if the domain users group has a DENY to write access, then it doesn't matter what you assign to the user elsewhere.

If you're sure this is not permissions you are going to have problems as what you're describing does sound very specific.
I'd create a share on another server or PC and see if the same issue applies there to. this will help you assess if it is a server problem or not.

Finally, check you do not have Quota's set on the drive. If the user has used up their quota they can only replace files of similar size, not create new ones.

edowningAuthor Commented:
I installed TrendMicro Antivirus that screwed it all up.
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.

Join & Write a Comment

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Tackle projects and never again get stuck behind a technical roadblock.
Join Now