Windows permissions inherit. That is, whatever permissions you grant someone in a folder, those permissions will apply to all that folder's subfolders and files.
In Windows, whenever you modify permissions, Windows physically writes the new permissions onto every subfolder (and file!). Therefore, if there are a lot of folders or files, it can take a very long time. This is normal and can't be avoided.
When we say a long time -- it's not unusual for it to take hours. For a big departmental filestore, it can even take days.
Windows permissions are built from small, individual building blocks. They are:
Full Control
Traverse Folder/Execute File
List Folder/Read Data
Read Attributes
Read Extended Attributes
Create Files/Write Data
Create Folders/Append Data
Write Attributes
Write Extended Attributes
Delete Subfolders and Files
Delete
Read Permissions
Change Permissions
Change Ownership
Synchronize
Most of these permissions have quite obscure purposes; it would be very difficult to construct working rights -- that did what you intended -- if you had to grant these individual permissions. You will probably be pleased to hear that we have no intention of making you work with these individual permissions. Instead, MyDrives will present you with a choice of three categories: Read-Only; Change (i.e. read/write); and Full Control (i.e. Read, Write and the ability to modify permissions). Each of these will set the necessary individual permissions.
Some of these permissions have different purposes depending on whether they are granted to a folder or a file. For example, consider List Folder/Read Data. When granted to a folder, it gives you the ability to see the existence of that folder. But when granted to a file, it allows you to read the contents of the file.
In addition, all of these permissions come in "Allow" and "Deny" flavors. So you can, for example, grant "Deny Full Control". However, in practice these permissions are extremely tricky to use. They trump all other permissions, so if from one source you inherit "Allow List Folders/Read Data", but from another you get "Deny Full Control", in practice you will have no rights whatsoever, because firstly the Deny permission always wins, but also denying Full Control actually means denying every one of the individual permissions that make up Full Control, thereby denying everything. Because these permissions are so hard to use and troubleshoot successfully, and because anything you want to do can be done without resorting to denying, MyDrives will only grant "Allow" permissions. It will, however, display "Deny" permissions that have been granted using a different method.
You might expect that when you grant permissions in a folder, everything below it would inherit those rights. Unfortunately, it isn't nearly so simple. Windows has seven different kinds of inheritance:
This folder only (i.e. don't inherit)
This folder, subfolders and files
This folder and subfolders
This folder and files
Subfolders and files only
Subfolders only
Files only
"This folder, subfolders and files" is the kind of inheritance we intuitively expect. The others are only required for very special purposes and are more likely to be confusing than useful. So to simplify, MyDrives will display the kind of inheritance a folder has, but will always use "This folder, subfolders and files" inheritance.
You might wonder why Microsoft feel it necessary to provide all these different kinds of inheritance. Part of the reason is the way some individual permissions grant one thing to folders but a completely different thing to files, e.g. List Folders/Read Files. In a normal Microsoft world, if you wanted to grant the ability for people to see folders only and nothing more, you would do this by granting List Folders/Read Files and applying the inheritance to "This folder and subfolders". Because the permission only applies to folders, it never accidentally grants Read Files. But more about that in the very next topic, "Access-Based Enumeration".
Imagine that you have List Folders/Read Files in Folder1. However, in one of its subfolders, Folder2, all permissions have been taken away from you. You might expect that when you click on Folder1, you would see all its contents except Folder2. Unfortunately, you would be wrong. You'll still see Folder2 -- but if you click on it, you'll get an Access Denied message. What's going on?
There's a huge difference between our intuitive expectations and how Windows actually thinks about rights. Intuitively, you expect things to which you don't have permissions to be hidden from you. But in the Microsoft world, if you have the List Folders permission, it does exactly that: It lists the contents of the folder. Obviously, all subfolders are part of the "contents" of the folder, as are all files. Thus you can see things you ultimately don't have permissions to do anything with.
This causes a lot of problems. Merely protecting something from further access isn't always sufficient (imagine you had a folder called Redundancies-ThisYear; unauthorized people even seeing its existence would be bad). Also, if you can see something, you assume you can open it. When you get Access Denied, you'll naturally think something is wrong and contact the helpdesk.
Microsoft eventually introduced a feature called Access-based Enumeration to try to resolve this. When you click on a folder, the server will first evaluate your permissions for each object in that folder and only show you those to which you have further permissions. This is a bolted-on attempt to approximate the way we intuitively expect it to behave.
However, it has one significant side effect: if you want to give people the ability only to see the existence of files (but not their contents), you can't. This is because in the Windows world, you'd do this by granting List Folders/Read Files, but only to folders. But as you click in one of the folders, Access-Based Enumeration would see that you had no further permissions to see the contents of the folder and filter them out. So although you can still grant these permissions, when Access-Based Enumeration is enabled, they simply won't work.
A folder inherits permissions from its parent.
There is a problem if you want to grant a user less permissions than they have in a parent folder (for example, a user may have Change, but in a child folder you wish to reduce their permissions to Read-Only). Windows does not handle this as you might expect. When you grant Read-Only in the child folder, the new explicit permissions don't override inherited permissions. So even though you have granted Read-Only, the user also continues to inherit Change.
Windows deals with this by blocking all permissions inherited from the parent. Even if you wish to reduce the permissions of only one user, Windows has to block them for everybody.
MyDrives handles this problem for you. If you grant permissions which amount to less than the permissions the user inherits from a higher folder, MyDrives will warn you, block inheritance, and then create new explicit permissions for everything which would have been inherited, except the user whose permissions you are reducing. MyDrives instead grants the new, reduced permissions to the user as you intended in the first place. This can be a bit surprising because lots of permissions may suddenly appear in the MyDrives window. These are just permissions that were previously inherited being made explicit.
Avoid using this. Imagine that you now want to grant permissions to a new user, from the very root of the filestore. Those new permissions will stop wherever they encounter an inheritance block! You end up having to keep track of where you have blocked inheritance, so that you can grant permissions there also, if appropriate. It's a nuisance. Generally speaking, users should have fewer permissions at higher levels, and acquire more permissions at lower levels as the folders become more relevant to them. If you find yourself having to block inheritance, it may mean that the filestore is not designed optimally. The folder where you are blocking inheritance probably should not be a child of its parent.
Of course there has to be a way for you to revert to inheriting permissions from above. MyDrives therefore includes the "Resume Inheriting" button. Clicking this button will remove the explicitly granted permissions, and remove the inheritance block, thereby allowing inherited permissions to flow through again.
If you move (not copy) a folder by dragging and dropping it somewhere else, its (supposedly inherited) permissions move with it!
Intuitively, you expect inheritance to mean that everything inside a folder just uses whatever the permissions are on that folder, right now. You'd expect that if you move something from that folder to another folder, it would just start using the permissions on its new parent folder. But Windows permissions only inherit at the time you apply them -- Windows actually writes those permissions onto every single subfolder and file. The permissions are physically part of each folder and file. So if you move something, the permissions go with it. The thing you moved still knows that it's theoretically supposed to be inheriting permissions, it just never checks whether it still is. Only the act of applying permissions checks what the current inheritance should be.
That's why MyDrives includes the "Reapply Rights" button. To fix a folder that has brought permissions with it, go to that folder's new parent and click "Reapply Rights". This will cause the permissions on the parent to be reapplied to its children, including the moved folder.
Be aware that, because it has to write permissions onto every subfolder and file, it will take a long time on complex structures.
Suppose another user's M: drive contains a folder A, which has a subfolder B, which in turn has a subfolder C. Suppose that user has granted you permissions in subfolder C only. In the normal Windows world, when you try to connect to that user's M: drive, you will be told that you don't have permissions to see it. Why?
Intuitively you expect that, if you have permissions in a subfolder, you should be able to see the existence of the intervening folders, to allow you to traverse from the root to where you have permissions. This isn't true in Windows. You can't browse unless you explicitly have permissions. It's normal, in the Windows world, for people to have to know the precise, exact path where they have permissions, and type that path exactly, rather than being able to start at a higher point and browse.
Since much of the point of MyDrives is to save you from having to do things like this, we have a workaround. MyDrives will do some extra work every time you grant permissions to anybody. In the present example, when the other user granted you permissions in subfolder C, MyDrives would also grant the absolute minimum permissions necessary to allow you to traverse folders A and B. These permissions don't let you see any other files or contents in those folders; they just let you see that the folders themselves exist. We call these permissions "Pass Through Folder".
Naturally, if you use a tool other than MyDrives to grant permissions, our special "Pass Through Folder" permissions won't be created.
Continuing with the current example, suppose the user drags subfolder C to somewhere else on their M: drive. You still have "Pass Through Folder" permissions in folders A and B, but they don't lead anywhere useful now, because folder C is gone. And wherever it was dropped, it's unlikely that you happen to have "Pass Through Folder" permissions in the intervening folders to allow you to browse to it.
To fix this problem, MyDrives has the "Fix Orphans" button. If anything has gone wrong with the "Pass Through Folder" permissions on a drive, you can run Fix Orphans. MyDrives will examine the entire structure (starting in the folder you are sitting in and working its way down through all subfolders), looking for "Pass Through Folder" permissions that don't lead anywhere, or other permissions that have been granted but don't have "Pass Through Folder" permissions leading to them. Be aware that, because it has to examine the permissions on every folder, it will take a long time on complex structures.
You may be accustomed to managing rights by right-clicking on a folder, choosing Properties, and going to the "NetWare Rights" tab. If you go to the analogous "Security" tab for a Windows drive, you can directly examine the permissions that you would normally use MyDrives to manage. If you do this, you will see lots of extra things that MyDrives doesn't show you. For example, here is the view of the root of an M: drive from MyDrives:
And here is the same thing from Windows Explorer:
MyDrives removes several things from the list, including SYSTEM, Administrators, Domain Admins, and some form of FilestoreAdmin. All of these are necessary for the proper working of your filestore. For example, they are necessary for the backup system to have sufficient permissions to be able to back up your filestore. If you were to remove them, the backup system would suddenly be unable to see the affected folders and would therefore not back them up. We would have no way of knowing this, because as far as the backup system would be concerned, they would simply not exist. We would only find out when you asked us to do a restore and found that we had no backups.
Also, these permissions are necessary for us to be able to fix your permissions should anything go wrong with them such that you no longer have the necessary permissions to change permissions yourself.
So, generally, these extra users are ones whom it would be a bad idea to remove. MyDrives therefore doesn't show them, to make it impossible to remove them.
You may also notice additional permissions for regular users, who you are quite sure you haven't granted rights to! What you are seeing is the "Pass Through Folder" permissions, which MyDrives normally hides to keep the interface from getting too busy. (After all, to keep things working, there can end up being an awful lot of "Pass Through Folder" permissions.) If you click on any of these unexpected users, you will notice that the permissions they have been granted are "Special". (The screenshot above shows one of these.)
Within MyDrives there is an option to allow you to see the "Pass Through Folder" permissions. In the Manage Rights window, if you tick the "Advanced Options" box, another box called "Show 'Pass Through Folder'" will appear. Use this box if you want to see them. Here's the same folder, but this time displaying Pass Through Folder permissions:
A "share" is a Windows way of making a resource available on the network. Novell didn't have them; you could connect a drive anywhere in the file system. Windows doesn't work this way; you have to explicitly make "shares". Users can only connect to these. You can, however, map a drive to any subdirectory of a share. But if a part of the file system is not shared, nobody will be able to map to it from the network.
Windows treats the root of a share as a special circumstance. If you want to make a modification to the permissions at the root of a share, no matter how trivial, Windows will warn you that whatever permissions you have just set thereby, it is going to ripple down through the entire directory structure below, replacing all permissions!
Imagine if you did this at the root of the share for all your filestore server's M: drives. All the permissions every single user had set, plus all the normal permissions that allow each user to see their own M: drive, would be wiped out.
In practice, it's highly unlikely that you will ever have the ability to change permissions at the root of a share. But MyDrives will be watching out for the problem anyway, and prevent you from doing it if it thinks it is happening. That's when you would get this message.