File Share in Windows Domain












3















How do you assign a single user (or a couple users) to a shared subfolder but restrict it for others?



My company and I are running into an issue with how our current file share environment was setup but instead of trying to fix the problems, we're going to rebuild the system on a new platform. This time we want to do it right from the ground up.



However, the problem we're running into is how to get away from assigning a single user permissions to access the folder. My understanding is that you assign a user to a (security) group and then add that group to the NTFS permissions. However, we have a number of folders where we need to give a specific user access to the folder, but not the users in that group.



My apologies if I'm not explaining it clearly. I'll try to clarify as best I can in responses.










share|improve this question























  • Use security group ?

    – yagmoth555
    7 hours ago
















3















How do you assign a single user (or a couple users) to a shared subfolder but restrict it for others?



My company and I are running into an issue with how our current file share environment was setup but instead of trying to fix the problems, we're going to rebuild the system on a new platform. This time we want to do it right from the ground up.



However, the problem we're running into is how to get away from assigning a single user permissions to access the folder. My understanding is that you assign a user to a (security) group and then add that group to the NTFS permissions. However, we have a number of folders where we need to give a specific user access to the folder, but not the users in that group.



My apologies if I'm not explaining it clearly. I'll try to clarify as best I can in responses.










share|improve this question























  • Use security group ?

    – yagmoth555
    7 hours ago














3












3








3








How do you assign a single user (or a couple users) to a shared subfolder but restrict it for others?



My company and I are running into an issue with how our current file share environment was setup but instead of trying to fix the problems, we're going to rebuild the system on a new platform. This time we want to do it right from the ground up.



However, the problem we're running into is how to get away from assigning a single user permissions to access the folder. My understanding is that you assign a user to a (security) group and then add that group to the NTFS permissions. However, we have a number of folders where we need to give a specific user access to the folder, but not the users in that group.



My apologies if I'm not explaining it clearly. I'll try to clarify as best I can in responses.










share|improve this question














How do you assign a single user (or a couple users) to a shared subfolder but restrict it for others?



My company and I are running into an issue with how our current file share environment was setup but instead of trying to fix the problems, we're going to rebuild the system on a new platform. This time we want to do it right from the ground up.



However, the problem we're running into is how to get away from assigning a single user permissions to access the folder. My understanding is that you assign a user to a (security) group and then add that group to the NTFS permissions. However, we have a number of folders where we need to give a specific user access to the folder, but not the users in that group.



My apologies if I'm not explaining it clearly. I'll try to clarify as best I can in responses.







network-share ntfs window-server-2012






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 8 hours ago









DavidDavid

264




264













  • Use security group ?

    – yagmoth555
    7 hours ago



















  • Use security group ?

    – yagmoth555
    7 hours ago

















Use security group ?

– yagmoth555
7 hours ago





Use security group ?

– yagmoth555
7 hours ago










3 Answers
3






active

oldest

votes


















3















My understanding is that you assign a user to a (security) group and
then add that group to the NTFS permissions. However, we have a number
of folders where we need to give a specific user access to the folder,
but not the users in that group.




That's the general rule, but if you need to assign permissions to only a single user you can certainly do that.



Another option would be to create a Security Group, add this lone user account to the group and assign permissions to that group. That way if you need to grant other users access to the folder you can simply add them to the group.






share|improve this answer
























  • joeqwerty... thank you for your prompt response. Are you saying that it IS ok to include an individual to a group share? I've always been told that you don't want to do that. But I think your second option would be the only way to go, however, I can see that getting ugly really quick.

    – David
    6 hours ago











  • It is OK if the situation warrants it. While best practice dictates that you should use Security Groups, it's not written in stone.

    – joeqwerty
    6 hours ago











  • As @joeqwerty says, best practice is to use groups to control access, then you can easily add/remove people from the groups as necessary. But it will work to also add individual users. The usual issue that when you start adjusting permission on that basis, you're more likely to forget what you've done - leave some account with access when you don't want to. If you document things well and if you're environment isn't too complex, it can work just fine to add individual users.

    – Ward
    6 hours ago





















2














A general rule of thumb is if the folder is for a specific user, i.e. a Home drive folder or a specific confidential scanned document share, then set the permissions for the individual user.



If the folder is for a department or a program/application, then create a security group for the specific use and add the user(s) to the group and assign permissions to the group.



This method allows for expansion down the road when they decide they want additional people to have access and if you ever need to do maintenance in the future or re-create a share it will be straight forward to the people managing as to who should have access.






share|improve this answer
























  • Tim, Much appreciated on the quick response. Currently, we're not using a "Home" drive but I have plans in the works to implement that. Just need the "go-ahead" from the people above. As far as the departmental shares go, I strongly believe in setting the permissions to a "department specific" group and adding the user to the group. But the issue I'm running into is with those few who are outside of the group, needing access to a specific subfolder (eg - IT needing access to \..HRIT) and nothing else. How would I keep "IT" out of the rest of the HR folder but giving access to the one?

    – David
    6 hours ago













  • You can grant them access just to the IT folder inside the HR folder. By default, all users have the "bypass traverse checking" user right which allows them to traverse a folder for which they DO NOT have permission to get to a folder for which they DO have permission. The user simply needs to enter the full path to the folder, they CANNOT browse to the folder.

    – joeqwerty
    4 hours ago













  • I wouldn't suggest doing nested permissions like that. It gets messy and you tend to forget that there is a sub folder with unique (non-inherited) permissions. Instead you should try and convince them to create a new share called HR-IT, or whatever, and create a new group that grants both departments access. Once you allow nested permissions and unique folder security like that you'll be hard pressed to get away from it and more and more requests will come in for additional "unique" security.

    – Tim Liston
    3 hours ago



















2














From the Linux perspective and sharing via Samba I set the top level share to be 770 with the setgid bit set (so all files/directories created retain the group owners ship of the top level of the share), and give access there to the foo group. Then create a subdirectory, set the perms the same way, but also change the group ownership to a group unique to the user(s) that need access to the restricted area foo-admins or whatever. This maps nicely to your security groups in Windows.



The issue when assigning the perms to the specific user Bob is that when Bob retires/drops dead/wins lotto and a replacement is hired, you have to hunt down all the "special" stuff owned by Bob and change the ownership/perms.



So from a cross platform perspective, go with the security groups model and not individual users beyond their $HOME share or equivalent. Makes the inevitable personnel change much easier to deal with.






share|improve this answer
























  • ivanivan, Thank you for your advice on this. Currently, right now, we're not using Linux for file sharing, but that's a good thing to know down the line when/if we go that route. Much appreciated.

    – David
    6 hours ago











  • @David thanks. Important part is to keep the same principles in mind - use groups, not individual users when assigning rights that others may need/inherit. Doesn't really matter what you are using to share with, it is how you are sharing that counts.

    – ivanivan
    6 hours ago













Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f950471%2ffile-share-in-windows-domain%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









3















My understanding is that you assign a user to a (security) group and
then add that group to the NTFS permissions. However, we have a number
of folders where we need to give a specific user access to the folder,
but not the users in that group.




That's the general rule, but if you need to assign permissions to only a single user you can certainly do that.



Another option would be to create a Security Group, add this lone user account to the group and assign permissions to that group. That way if you need to grant other users access to the folder you can simply add them to the group.






share|improve this answer
























  • joeqwerty... thank you for your prompt response. Are you saying that it IS ok to include an individual to a group share? I've always been told that you don't want to do that. But I think your second option would be the only way to go, however, I can see that getting ugly really quick.

    – David
    6 hours ago











  • It is OK if the situation warrants it. While best practice dictates that you should use Security Groups, it's not written in stone.

    – joeqwerty
    6 hours ago











  • As @joeqwerty says, best practice is to use groups to control access, then you can easily add/remove people from the groups as necessary. But it will work to also add individual users. The usual issue that when you start adjusting permission on that basis, you're more likely to forget what you've done - leave some account with access when you don't want to. If you document things well and if you're environment isn't too complex, it can work just fine to add individual users.

    – Ward
    6 hours ago


















3















My understanding is that you assign a user to a (security) group and
then add that group to the NTFS permissions. However, we have a number
of folders where we need to give a specific user access to the folder,
but not the users in that group.




That's the general rule, but if you need to assign permissions to only a single user you can certainly do that.



Another option would be to create a Security Group, add this lone user account to the group and assign permissions to that group. That way if you need to grant other users access to the folder you can simply add them to the group.






share|improve this answer
























  • joeqwerty... thank you for your prompt response. Are you saying that it IS ok to include an individual to a group share? I've always been told that you don't want to do that. But I think your second option would be the only way to go, however, I can see that getting ugly really quick.

    – David
    6 hours ago











  • It is OK if the situation warrants it. While best practice dictates that you should use Security Groups, it's not written in stone.

    – joeqwerty
    6 hours ago











  • As @joeqwerty says, best practice is to use groups to control access, then you can easily add/remove people from the groups as necessary. But it will work to also add individual users. The usual issue that when you start adjusting permission on that basis, you're more likely to forget what you've done - leave some account with access when you don't want to. If you document things well and if you're environment isn't too complex, it can work just fine to add individual users.

    – Ward
    6 hours ago
















3












3








3








My understanding is that you assign a user to a (security) group and
then add that group to the NTFS permissions. However, we have a number
of folders where we need to give a specific user access to the folder,
but not the users in that group.




That's the general rule, but if you need to assign permissions to only a single user you can certainly do that.



Another option would be to create a Security Group, add this lone user account to the group and assign permissions to that group. That way if you need to grant other users access to the folder you can simply add them to the group.






share|improve this answer














My understanding is that you assign a user to a (security) group and
then add that group to the NTFS permissions. However, we have a number
of folders where we need to give a specific user access to the folder,
but not the users in that group.




That's the general rule, but if you need to assign permissions to only a single user you can certainly do that.



Another option would be to create a Security Group, add this lone user account to the group and assign permissions to that group. That way if you need to grant other users access to the folder you can simply add them to the group.







share|improve this answer












share|improve this answer



share|improve this answer










answered 7 hours ago









joeqwertyjoeqwerty

95.7k463149




95.7k463149













  • joeqwerty... thank you for your prompt response. Are you saying that it IS ok to include an individual to a group share? I've always been told that you don't want to do that. But I think your second option would be the only way to go, however, I can see that getting ugly really quick.

    – David
    6 hours ago











  • It is OK if the situation warrants it. While best practice dictates that you should use Security Groups, it's not written in stone.

    – joeqwerty
    6 hours ago











  • As @joeqwerty says, best practice is to use groups to control access, then you can easily add/remove people from the groups as necessary. But it will work to also add individual users. The usual issue that when you start adjusting permission on that basis, you're more likely to forget what you've done - leave some account with access when you don't want to. If you document things well and if you're environment isn't too complex, it can work just fine to add individual users.

    – Ward
    6 hours ago





















  • joeqwerty... thank you for your prompt response. Are you saying that it IS ok to include an individual to a group share? I've always been told that you don't want to do that. But I think your second option would be the only way to go, however, I can see that getting ugly really quick.

    – David
    6 hours ago











  • It is OK if the situation warrants it. While best practice dictates that you should use Security Groups, it's not written in stone.

    – joeqwerty
    6 hours ago











  • As @joeqwerty says, best practice is to use groups to control access, then you can easily add/remove people from the groups as necessary. But it will work to also add individual users. The usual issue that when you start adjusting permission on that basis, you're more likely to forget what you've done - leave some account with access when you don't want to. If you document things well and if you're environment isn't too complex, it can work just fine to add individual users.

    – Ward
    6 hours ago



















joeqwerty... thank you for your prompt response. Are you saying that it IS ok to include an individual to a group share? I've always been told that you don't want to do that. But I think your second option would be the only way to go, however, I can see that getting ugly really quick.

– David
6 hours ago





joeqwerty... thank you for your prompt response. Are you saying that it IS ok to include an individual to a group share? I've always been told that you don't want to do that. But I think your second option would be the only way to go, however, I can see that getting ugly really quick.

– David
6 hours ago













It is OK if the situation warrants it. While best practice dictates that you should use Security Groups, it's not written in stone.

– joeqwerty
6 hours ago





It is OK if the situation warrants it. While best practice dictates that you should use Security Groups, it's not written in stone.

– joeqwerty
6 hours ago













As @joeqwerty says, best practice is to use groups to control access, then you can easily add/remove people from the groups as necessary. But it will work to also add individual users. The usual issue that when you start adjusting permission on that basis, you're more likely to forget what you've done - leave some account with access when you don't want to. If you document things well and if you're environment isn't too complex, it can work just fine to add individual users.

– Ward
6 hours ago







As @joeqwerty says, best practice is to use groups to control access, then you can easily add/remove people from the groups as necessary. But it will work to also add individual users. The usual issue that when you start adjusting permission on that basis, you're more likely to forget what you've done - leave some account with access when you don't want to. If you document things well and if you're environment isn't too complex, it can work just fine to add individual users.

– Ward
6 hours ago















2














A general rule of thumb is if the folder is for a specific user, i.e. a Home drive folder or a specific confidential scanned document share, then set the permissions for the individual user.



If the folder is for a department or a program/application, then create a security group for the specific use and add the user(s) to the group and assign permissions to the group.



This method allows for expansion down the road when they decide they want additional people to have access and if you ever need to do maintenance in the future or re-create a share it will be straight forward to the people managing as to who should have access.






share|improve this answer
























  • Tim, Much appreciated on the quick response. Currently, we're not using a "Home" drive but I have plans in the works to implement that. Just need the "go-ahead" from the people above. As far as the departmental shares go, I strongly believe in setting the permissions to a "department specific" group and adding the user to the group. But the issue I'm running into is with those few who are outside of the group, needing access to a specific subfolder (eg - IT needing access to \..HRIT) and nothing else. How would I keep "IT" out of the rest of the HR folder but giving access to the one?

    – David
    6 hours ago













  • You can grant them access just to the IT folder inside the HR folder. By default, all users have the "bypass traverse checking" user right which allows them to traverse a folder for which they DO NOT have permission to get to a folder for which they DO have permission. The user simply needs to enter the full path to the folder, they CANNOT browse to the folder.

    – joeqwerty
    4 hours ago













  • I wouldn't suggest doing nested permissions like that. It gets messy and you tend to forget that there is a sub folder with unique (non-inherited) permissions. Instead you should try and convince them to create a new share called HR-IT, or whatever, and create a new group that grants both departments access. Once you allow nested permissions and unique folder security like that you'll be hard pressed to get away from it and more and more requests will come in for additional "unique" security.

    – Tim Liston
    3 hours ago
















2














A general rule of thumb is if the folder is for a specific user, i.e. a Home drive folder or a specific confidential scanned document share, then set the permissions for the individual user.



If the folder is for a department or a program/application, then create a security group for the specific use and add the user(s) to the group and assign permissions to the group.



This method allows for expansion down the road when they decide they want additional people to have access and if you ever need to do maintenance in the future or re-create a share it will be straight forward to the people managing as to who should have access.






share|improve this answer
























  • Tim, Much appreciated on the quick response. Currently, we're not using a "Home" drive but I have plans in the works to implement that. Just need the "go-ahead" from the people above. As far as the departmental shares go, I strongly believe in setting the permissions to a "department specific" group and adding the user to the group. But the issue I'm running into is with those few who are outside of the group, needing access to a specific subfolder (eg - IT needing access to \..HRIT) and nothing else. How would I keep "IT" out of the rest of the HR folder but giving access to the one?

    – David
    6 hours ago













  • You can grant them access just to the IT folder inside the HR folder. By default, all users have the "bypass traverse checking" user right which allows them to traverse a folder for which they DO NOT have permission to get to a folder for which they DO have permission. The user simply needs to enter the full path to the folder, they CANNOT browse to the folder.

    – joeqwerty
    4 hours ago













  • I wouldn't suggest doing nested permissions like that. It gets messy and you tend to forget that there is a sub folder with unique (non-inherited) permissions. Instead you should try and convince them to create a new share called HR-IT, or whatever, and create a new group that grants both departments access. Once you allow nested permissions and unique folder security like that you'll be hard pressed to get away from it and more and more requests will come in for additional "unique" security.

    – Tim Liston
    3 hours ago














2












2








2







A general rule of thumb is if the folder is for a specific user, i.e. a Home drive folder or a specific confidential scanned document share, then set the permissions for the individual user.



If the folder is for a department or a program/application, then create a security group for the specific use and add the user(s) to the group and assign permissions to the group.



This method allows for expansion down the road when they decide they want additional people to have access and if you ever need to do maintenance in the future or re-create a share it will be straight forward to the people managing as to who should have access.






share|improve this answer













A general rule of thumb is if the folder is for a specific user, i.e. a Home drive folder or a specific confidential scanned document share, then set the permissions for the individual user.



If the folder is for a department or a program/application, then create a security group for the specific use and add the user(s) to the group and assign permissions to the group.



This method allows for expansion down the road when they decide they want additional people to have access and if you ever need to do maintenance in the future or re-create a share it will be straight forward to the people managing as to who should have access.







share|improve this answer












share|improve this answer



share|improve this answer










answered 7 hours ago









Tim ListonTim Liston

4215




4215













  • Tim, Much appreciated on the quick response. Currently, we're not using a "Home" drive but I have plans in the works to implement that. Just need the "go-ahead" from the people above. As far as the departmental shares go, I strongly believe in setting the permissions to a "department specific" group and adding the user to the group. But the issue I'm running into is with those few who are outside of the group, needing access to a specific subfolder (eg - IT needing access to \..HRIT) and nothing else. How would I keep "IT" out of the rest of the HR folder but giving access to the one?

    – David
    6 hours ago













  • You can grant them access just to the IT folder inside the HR folder. By default, all users have the "bypass traverse checking" user right which allows them to traverse a folder for which they DO NOT have permission to get to a folder for which they DO have permission. The user simply needs to enter the full path to the folder, they CANNOT browse to the folder.

    – joeqwerty
    4 hours ago













  • I wouldn't suggest doing nested permissions like that. It gets messy and you tend to forget that there is a sub folder with unique (non-inherited) permissions. Instead you should try and convince them to create a new share called HR-IT, or whatever, and create a new group that grants both departments access. Once you allow nested permissions and unique folder security like that you'll be hard pressed to get away from it and more and more requests will come in for additional "unique" security.

    – Tim Liston
    3 hours ago



















  • Tim, Much appreciated on the quick response. Currently, we're not using a "Home" drive but I have plans in the works to implement that. Just need the "go-ahead" from the people above. As far as the departmental shares go, I strongly believe in setting the permissions to a "department specific" group and adding the user to the group. But the issue I'm running into is with those few who are outside of the group, needing access to a specific subfolder (eg - IT needing access to \..HRIT) and nothing else. How would I keep "IT" out of the rest of the HR folder but giving access to the one?

    – David
    6 hours ago













  • You can grant them access just to the IT folder inside the HR folder. By default, all users have the "bypass traverse checking" user right which allows them to traverse a folder for which they DO NOT have permission to get to a folder for which they DO have permission. The user simply needs to enter the full path to the folder, they CANNOT browse to the folder.

    – joeqwerty
    4 hours ago













  • I wouldn't suggest doing nested permissions like that. It gets messy and you tend to forget that there is a sub folder with unique (non-inherited) permissions. Instead you should try and convince them to create a new share called HR-IT, or whatever, and create a new group that grants both departments access. Once you allow nested permissions and unique folder security like that you'll be hard pressed to get away from it and more and more requests will come in for additional "unique" security.

    – Tim Liston
    3 hours ago

















Tim, Much appreciated on the quick response. Currently, we're not using a "Home" drive but I have plans in the works to implement that. Just need the "go-ahead" from the people above. As far as the departmental shares go, I strongly believe in setting the permissions to a "department specific" group and adding the user to the group. But the issue I'm running into is with those few who are outside of the group, needing access to a specific subfolder (eg - IT needing access to \..HRIT) and nothing else. How would I keep "IT" out of the rest of the HR folder but giving access to the one?

– David
6 hours ago







Tim, Much appreciated on the quick response. Currently, we're not using a "Home" drive but I have plans in the works to implement that. Just need the "go-ahead" from the people above. As far as the departmental shares go, I strongly believe in setting the permissions to a "department specific" group and adding the user to the group. But the issue I'm running into is with those few who are outside of the group, needing access to a specific subfolder (eg - IT needing access to \..HRIT) and nothing else. How would I keep "IT" out of the rest of the HR folder but giving access to the one?

– David
6 hours ago















You can grant them access just to the IT folder inside the HR folder. By default, all users have the "bypass traverse checking" user right which allows them to traverse a folder for which they DO NOT have permission to get to a folder for which they DO have permission. The user simply needs to enter the full path to the folder, they CANNOT browse to the folder.

– joeqwerty
4 hours ago







You can grant them access just to the IT folder inside the HR folder. By default, all users have the "bypass traverse checking" user right which allows them to traverse a folder for which they DO NOT have permission to get to a folder for which they DO have permission. The user simply needs to enter the full path to the folder, they CANNOT browse to the folder.

– joeqwerty
4 hours ago















I wouldn't suggest doing nested permissions like that. It gets messy and you tend to forget that there is a sub folder with unique (non-inherited) permissions. Instead you should try and convince them to create a new share called HR-IT, or whatever, and create a new group that grants both departments access. Once you allow nested permissions and unique folder security like that you'll be hard pressed to get away from it and more and more requests will come in for additional "unique" security.

– Tim Liston
3 hours ago





I wouldn't suggest doing nested permissions like that. It gets messy and you tend to forget that there is a sub folder with unique (non-inherited) permissions. Instead you should try and convince them to create a new share called HR-IT, or whatever, and create a new group that grants both departments access. Once you allow nested permissions and unique folder security like that you'll be hard pressed to get away from it and more and more requests will come in for additional "unique" security.

– Tim Liston
3 hours ago











2














From the Linux perspective and sharing via Samba I set the top level share to be 770 with the setgid bit set (so all files/directories created retain the group owners ship of the top level of the share), and give access there to the foo group. Then create a subdirectory, set the perms the same way, but also change the group ownership to a group unique to the user(s) that need access to the restricted area foo-admins or whatever. This maps nicely to your security groups in Windows.



The issue when assigning the perms to the specific user Bob is that when Bob retires/drops dead/wins lotto and a replacement is hired, you have to hunt down all the "special" stuff owned by Bob and change the ownership/perms.



So from a cross platform perspective, go with the security groups model and not individual users beyond their $HOME share or equivalent. Makes the inevitable personnel change much easier to deal with.






share|improve this answer
























  • ivanivan, Thank you for your advice on this. Currently, right now, we're not using Linux for file sharing, but that's a good thing to know down the line when/if we go that route. Much appreciated.

    – David
    6 hours ago











  • @David thanks. Important part is to keep the same principles in mind - use groups, not individual users when assigning rights that others may need/inherit. Doesn't really matter what you are using to share with, it is how you are sharing that counts.

    – ivanivan
    6 hours ago


















2














From the Linux perspective and sharing via Samba I set the top level share to be 770 with the setgid bit set (so all files/directories created retain the group owners ship of the top level of the share), and give access there to the foo group. Then create a subdirectory, set the perms the same way, but also change the group ownership to a group unique to the user(s) that need access to the restricted area foo-admins or whatever. This maps nicely to your security groups in Windows.



The issue when assigning the perms to the specific user Bob is that when Bob retires/drops dead/wins lotto and a replacement is hired, you have to hunt down all the "special" stuff owned by Bob and change the ownership/perms.



So from a cross platform perspective, go with the security groups model and not individual users beyond their $HOME share or equivalent. Makes the inevitable personnel change much easier to deal with.






share|improve this answer
























  • ivanivan, Thank you for your advice on this. Currently, right now, we're not using Linux for file sharing, but that's a good thing to know down the line when/if we go that route. Much appreciated.

    – David
    6 hours ago











  • @David thanks. Important part is to keep the same principles in mind - use groups, not individual users when assigning rights that others may need/inherit. Doesn't really matter what you are using to share with, it is how you are sharing that counts.

    – ivanivan
    6 hours ago
















2












2








2







From the Linux perspective and sharing via Samba I set the top level share to be 770 with the setgid bit set (so all files/directories created retain the group owners ship of the top level of the share), and give access there to the foo group. Then create a subdirectory, set the perms the same way, but also change the group ownership to a group unique to the user(s) that need access to the restricted area foo-admins or whatever. This maps nicely to your security groups in Windows.



The issue when assigning the perms to the specific user Bob is that when Bob retires/drops dead/wins lotto and a replacement is hired, you have to hunt down all the "special" stuff owned by Bob and change the ownership/perms.



So from a cross platform perspective, go with the security groups model and not individual users beyond their $HOME share or equivalent. Makes the inevitable personnel change much easier to deal with.






share|improve this answer













From the Linux perspective and sharing via Samba I set the top level share to be 770 with the setgid bit set (so all files/directories created retain the group owners ship of the top level of the share), and give access there to the foo group. Then create a subdirectory, set the perms the same way, but also change the group ownership to a group unique to the user(s) that need access to the restricted area foo-admins or whatever. This maps nicely to your security groups in Windows.



The issue when assigning the perms to the specific user Bob is that when Bob retires/drops dead/wins lotto and a replacement is hired, you have to hunt down all the "special" stuff owned by Bob and change the ownership/perms.



So from a cross platform perspective, go with the security groups model and not individual users beyond their $HOME share or equivalent. Makes the inevitable personnel change much easier to deal with.







share|improve this answer












share|improve this answer



share|improve this answer










answered 6 hours ago









ivanivanivanivan

87536




87536













  • ivanivan, Thank you for your advice on this. Currently, right now, we're not using Linux for file sharing, but that's a good thing to know down the line when/if we go that route. Much appreciated.

    – David
    6 hours ago











  • @David thanks. Important part is to keep the same principles in mind - use groups, not individual users when assigning rights that others may need/inherit. Doesn't really matter what you are using to share with, it is how you are sharing that counts.

    – ivanivan
    6 hours ago





















  • ivanivan, Thank you for your advice on this. Currently, right now, we're not using Linux for file sharing, but that's a good thing to know down the line when/if we go that route. Much appreciated.

    – David
    6 hours ago











  • @David thanks. Important part is to keep the same principles in mind - use groups, not individual users when assigning rights that others may need/inherit. Doesn't really matter what you are using to share with, it is how you are sharing that counts.

    – ivanivan
    6 hours ago



















ivanivan, Thank you for your advice on this. Currently, right now, we're not using Linux for file sharing, but that's a good thing to know down the line when/if we go that route. Much appreciated.

– David
6 hours ago





ivanivan, Thank you for your advice on this. Currently, right now, we're not using Linux for file sharing, but that's a good thing to know down the line when/if we go that route. Much appreciated.

– David
6 hours ago













@David thanks. Important part is to keep the same principles in mind - use groups, not individual users when assigning rights that others may need/inherit. Doesn't really matter what you are using to share with, it is how you are sharing that counts.

– ivanivan
6 hours ago







@David thanks. Important part is to keep the same principles in mind - use groups, not individual users when assigning rights that others may need/inherit. Doesn't really matter what you are using to share with, it is how you are sharing that counts.

– ivanivan
6 hours ago




















draft saved

draft discarded




















































Thanks for contributing an answer to Server Fault!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f950471%2ffile-share-in-windows-domain%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

How to make a Squid Proxy server?

Is this a new Fibonacci Identity?

Touch on Surface Book