I have a folder which has permissions on it for our IIS user. This folder is currently shared so our code deployment user can move files onto it.
I attempted adding another user to the share through the folder properties>Sharing>Share and added a user there. Then IIS went down so I checked and sure enough it appeared that setting the share permissions removed the local folder permissions for the IIS user.
How do I add a user to the share without removing users from accessing it locally?
start over and create a local or domain group, and give the access for this new group. Any new users you need to give access to, you can just add them to this group.
Not sure exacrtly what you mean by "setting the share permissions removed the local folder permissions for the IIS user" (did the permission disappear, or just not get applied as expected?), but you should understand that Windows applies the most restrictive permission of the NTFS and Share permissions set on the object. Perhaps this explains what you experienced.
The Microsoft Technet article on Share and NTFS permissions in Windows 2008 suggests:
This seems like a good standard approach to take, and in conjunction with whizkids suggestion to use groups reduces administrative overhead.
I realise this is a 5 year old question, but I can verify the OP's problem. I have a folder with NTFS Security Permissions set to (MyServer/Users) group as IIS Application Identity is created in this group. I then added a share to the same folder, for remote file access. The website then crashed. Rechecking NTFS Security Permissions, and that group had been removed from the list previously set. TechNet says Share Permissions & NTFS Security Settings are seperate, changing one will not affect the other, but thats clearly not the case. We re-added the NTFS permissions for (MyServer/Users) group & it worked again. I guess its still a bug many years on.
That's not expected behavior. I would test a couple other times and see if you can find the pattern. Adding a user through the GUI should never remove another user.
Did you change inheritance, or cleanup a user that had a GUID name, or something else at the same time? Or after creating the share, did you 'move' files over? Moving from the same volume will bring the original permissions with it and will not inherit.
I suspect that some other factor besides the share permission addition caused this to occur.
Now an almost 9 year old question, and we just 'learned' the same thing. We have (2) local users set up with inherited read permissions, and local write permissions. If we share the folder, it removes the two users completely. We can put the permissions back after the share, but it definitely stripped them out.
If the local users have FULL CONTROL, it does not remove them. Alternatively, when doing the share, if we change access from CUSTOM to READ/WRITE, it also keeps, though changes, the permissions. We did not try other combinations.