Suppose you are asked to create a share on the NT server and to give certain users readonly access, while giving others r/w access. Here is some info which might help. If you don't have time to read the explanation, you can skip right to the example procedure near the end of this document.

---

Philosophy

• Never nest shares. A share should never have a subdirectory that is also shared (unless you are doing something fancy, which is beyond the scope of this article).
• Do not put any shares in the system partition that users can write to. Since NT Server lacks directory quota tools, this would enable the users to fill up the system disk, possibly crashing the server.
• When choosing which partition to put the shared dir on, consider what other shares and apps use that partition. Any one share can suddenly consume all of the free space in the partition, taking away free space from all of the other shares. (This is again because of NT's lack of a quota mechanism.) If the share is for a critical app, consider putting it on it's own partition. Try to put user partitions or scratch partitions together so that they only have each other to contend with.
• Give "everyone" full access to the shared dir and all of its subdirs at the file system level, and use the share permissions to control access.

---

In a nutshell

• Use share permissions, not file system permissions, to manage access over the network.
• Assign rights to local groups.
• Put global groups and/or user accounts into the local groups that have the rights they need.
• You can put users and/or global groups from another domain into your local groups if that domain is trusted by yours.

---

NT Server 4's algorithm for computing effective rights

Here's how to compute what rights an account has to a resource:

File system rights = the union (OR) of the user rights and the rights of all groups that the user is in
Share rights = the union (OR) of the user rights and the rights of all groups that the user is in
Effective rights = the intersection (AND) of the file system and the share rights

In other words, for a user to have a given right to a resource, the user must have that right at BOTH the file system level and the share level. The user earns these rights either explicitly or by membership in a group that has the rights.

There is one exception: if the user or any group the user is in is explicitly assigned "no rights", the user will have "no rights", period. This overrides rights the user may have been granted any other way.

At least I think that's how it works!

---

Example procedure

1. Figure out where on the server's disk you want to put the shared directory. Create the directory. Figure out what you want the sharename to be. It helps to have the directory name same as the sharename (it's easire for other admins to find that way). I like to always put shares below a subdirectory called "data" off the root. I never put shared dirs on the root. For the rest of this example, let's assume the sharename is "bikes" and the server name is "prod".
   
   
2. Make sure "everyone" has "full control" to the directory at the file system level (this is under the "permissions" button in the "file system" tab when you right click the directory in Explorer). Include the subdirectories too.
   
   
3. Go into User Manager.  Create the following local groups:

 

group type	group name	group description
local	bikes read	Members can read prod-bikes
local	bikes write	Members can r/w prod-bikes

 
4. Go back to the "\\prod\bikes" share. Give only the following permissions:

 

User or group	Share permissions
administrators (optional)	full control
bikes read	read
bikes write	change

Note that you might not be able to pick the groups you created from the list right after you made them. For some reason, even on the same server as you just made the groups, they may not appear in the pick list for a few minutes. If they are not in the list, close it and try again later.
 
5. Now you can assign permissions to users or global groups by putting them in the correct local groups. For instance, if the global group "bike racing team" needs readonly, "bike repair dept" needs read/write, the group "site coords" in the domain "France" (a seperate domain from yours that your domain trusts) needs r/w, and the user "Joe Schlabotnick" needs readonly, you would set it up as follows:

 

Local group	Membership
bikes read	Joe Schlabotnick bike racing team
bikes write	bike repair dept France\site coords

Note that if your domain does not trust the domain "France", you will not see that domain name in the pick list when you try to change which domain's users and groups you are assigning to the group.


6. From now on, when a new user or group needs access, you can (and should) do it all from User Manager! Remember that they have to log in again before any new group membership you establish takes effect.