Solved

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

Posted on 2011-03-01
11
740 Views
Last Modified: 2012-05-11
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?

Thanks,
Eric
0
Comment
Question by:edowning
11 Comments
 
LVL 5

Expert Comment

by:darrylka
ID: 35009946
Are you setting the permissions for the directory itself, or are you setting them in the "Sharing" permissions?
0
 
LVL 8

Expert Comment

by:devinnoel
ID: 35009956
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.
0
 
LVL 20

Expert Comment

by:woolnoir
ID: 35009990
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.
0
 

Author Comment

by:edowning
ID: 35009994
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.
0
 

Author Comment

by:edowning
ID: 35010037
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 =)
0
 

Author Comment

by:edowning
ID: 35010082
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?
0
 

Author Comment

by:edowning
ID: 35010145
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.
0
 
LVL 8

Expert Comment

by:devinnoel
ID: 35010479
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.
0
 

Accepted Solution

by:
edowning earned 0 total points
ID: 35011312
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.

0
 
LVL 27

Expert Comment

by:Steve
ID: 35011972
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.

0
 

Author Closing Comment

by:edowning
ID: 35045667
I installed TrendMicro Antivirus that screwed it all up.
0

Join & Write a Comment

As network administrators; we know how hard it is to track user’s login/logout using security event log (BTW it is harder now in windows 2008 because user name is always “N/A” in the grid), and most of us either get 3rd party tools, or just make our…
Introduction You may have a need to setup a group of users to allow local administrative access on workstations.  In a domain environment this can easily be achieved with Restricted Groups and Group Policies. This article will demonstrate how to…
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlle…

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now