Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Windows Server 2012 Shared Folder permissions issues !!


  • Please log in to reply
4 replies to this topic

#1 openmind1188

openmind1188

  • Members
  • 1 posts
  • OFFLINE
  •  
  • Local time:11:19 PM

Posted 05 July 2015 - 06:22 AM

Dear All,

We are using Windows Server 2012R2 for sharing folders on the network.

Our requirement is :
1. Around 8 Shared folders
2. Depends on folder we need to give Modify permission for small group, Read+Write for another group and R+W permissions including Modify permission on some subfolder for small group.
3. Before I used to do settings from Folder->properties->share - allowing people to Read/Write and then go to security tab, there I edit permissions accordingly.

But don't know where I am doing wrong, may be confused with Share permissions and NTFS permissions. And having issues now that user is able change permissions on some files/folder by going to Properties !

Was thinking to remove sharing and do it again from scratch to avoid confusion and conflict.

Please guide me to fulfill #2 (above point ) requirements.


Looking forward for your suggestions !



BC AdBot (Login to Remove)

 


#2 sflatechguy

sflatechguy

  • BC Advisor
  • 2,242 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:04:19 PM

Posted 05 July 2015 - 11:25 AM

Sharing simply makes the folder available; you can share a folder, but users still need NTFS permissions in order to enter it and read the contents.

 

Permisssions are set through NTFS. Best way to manage those are to create security groups you want to have the various permissions, and then add users to those groups.

 

To give users modify permission on subfolders but not the parent folders, you'll probably want to block inheritance of permissions for the subfolders.



#3 x64

x64

  • Members
  • 352 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:London UK
  • Local time:09:19 PM

Posted 05 July 2015 - 01:47 PM

Putting it a slightly different way (and ease any confusion between Share and NTFS permissions), the primary set of permissions for access to a particular file or folder are the NTFS permissions. These are the permissions that would apply if you were accessing the file/folder locally on the computer hosting the file (without going through a share). However when accessing the file/folder through a share, the permissions that the remote user, are the NTFS permissions MASKED by the Share permissions.

 

So set the NTFS permissions for the actual permissions that you want the users to have (these can be a complex hierarchy if you feel so inclined), and set the Share permissions to admit just the users that you want to have remote access, with the greatest permission that they have anywhere in the tree of file of folders.

 

Re your point #2 I'm not sure if you are getting confused - you seem to be saying R+W a lot and modify elsewhere, and not only Read anywhere... If your last example was to say give group "Managers" full r/w access to the entire share and the "Staff" group Read only access to the entire share except for the "Widgets" subfolder, which that should have Modify (effective r/w) access to then you could do this. Let's say the share will be called "Stock" and be located at D:\Data\Stock on the host system.

 

You would add the "Managers" group to the NTFS permissions for D:\Data\Stock with Modify access, and the "staff" group there with just Read+Execute permission. Then on the Widgets subfolder (D:\Data\Stock\Widgets) additionally add the staff group with Modify access.

 

THEN on the share permissions, just add "Managers" with Modify, and "Staff" also with Modify (Modify being the greatest permissions that Staff have SOMEWHERE in the share).

 

There will probably already be some NTFS permissions on the "D:\Data\Stock" This may grant Administrative full access, and r/o access for a "users" group (And a mysterious thing called System). It's probably OK to leave those permissions in (as the Share permissions will limit access by other users) You could block inheritance for the 'Users' group, but, that might be a step too far for now (until you get the hang of what I suggested above - Oh and until you REALLY have lot experience - don't remove "System" from permissions lists)

 

x64



#4 hrohal

hrohal

  • Members
  • 1 posts
  • OFFLINE
  •  
  • Local time:01:49 AM

Posted 05 July 2017 - 04:19 AM

Hi openmind1188, 

Did you get any solution to this, it looks to be an issue with Server 2012 specifically and Microsoft mush have released some patch to fix it?

 

For other guys who have commented so far on this post: Issue is between RW permission and Modify permission. If we give RW permission only users are unable to make the changes on the network shared files, they get error permission denied.



#5 x64

x64

  • Members
  • 352 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:London UK
  • Local time:09:19 PM

Posted 05 July 2017 - 12:38 PM

Define exactly what you mean by RW permission - which permissions and scopes of those permissions exactly?

 

 

Also define what you mean by 'changes' - through which application? What kind of change, how is the change being committed to disk? 

 

As fas as I know the only permission issues for the old style ntfs file and folder permissions are occasionally issues when ACL entries do not get written to the ACL in the correct order. This would not be an issue for the kinds of permissions that were the subject of this thread.

 

x64






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users