Don't grant Filestore Administrator unless you want the user to be able to grant rights to others.
Whatever rights you grant someone in a folder, those rights will be inherited by all that folder's subfolders and files.
When you modify rights, Windows writes the new rights onto each subfolder and file, so 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 take days.)
Your filestore will have at least two administrators. Coordinate among yourselves when making rights changes. You must never have more than one person making rights changes at the same time. You will overwrite each other's changes.
The purpose of MyDrives' rights management feature is to save you from having to understand the full complexity of Windows rights. But if you want to know more, see The Not-So-Basics.
There is a problem if you want to grant a user less rights than they inherit from the parent folder. For example, a user may have Read, Write and Delete, but in a child folder you wish to reduce their rights to Read-Only. But when you grant Read-Only in the child folder, the new explicit rights don't override inherited rights. The user also continues to inherit Read, Write and Delete.
Windows can only reduce rights by blocking all rights inherited from the parent. Even to reduce the rights of just one user, Windows has to block them for everybody.
Avoid using this. Imagine that you now create a new Filestore Administrator, on the root of the filestore. Those new rights will stop wherever they encounter an inheritance block! You have to keep track of where you have blocked inheritance, so that you can grant rights there also, if appropriate. It's complicated, and easy to make mistakes. Generally speaking, users should have fewer rights at higher levels, and gain rights at lower levels as the folders become more relevant to them. If you find yourself having to block inheritance, the folder where you are doing it probably shouldn't be a child of its parent.
If you must do it, MyDrives handles it for you. If you click Stop Inheriting, or grant rights which are less than what the user inherits, MyDrives will warn you, block inheritance, and then create new explicit rights for everything that would have been inherited. This can be a bit surprising because lots of rights may suddenly appear. These are just rights that were previously inherited, being made explicit.
Of course there has to be a way to revert to inheriting rights. MyDrives therefore has the "Resume Inheriting" button. Clicking it will remove the explicitly granted rights, and remove the inheritance block, thereby allowing inherited rights to flow through again.
If you move (not copy) a folder by dragging and dropping it somewhere else, its rights move with it!
Intuitively, you expect that if you move something to another folder, the rights on its parent will apply to it. But Windows rights only inherit at the time you apply them -- Windows actually writes those rights onto every single subfolder and file. So if you move something, the rights move with it. The thing you moved still knows that it's theoretically supposed to be inheriting rights, it just never checks whether it still is.
That's why MyDrives includes the "Reapply Rights" button. To fix a folder that has brought rights with it, go to that folder's new parent and click "Reapply Rights". This will cause the rights on the parent to be reapplied to its children, including the moved folder.
Be aware that, because it has to write rights onto every subfolder and file, it will take a long time on complex structures.
Suppose Mary's M: drive contains a folder A, which has a subfolder B, which in turn has a subfolder C. Mary has granted you rights in subfolder C only. In the normal Windows world, when you try to connect to Mary's M: drive, you will be told that you don't have rights to see it. Why?
Intuitively you expect that, if you have rights 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 rights. This isn't true in Windows. It's normal, in the Windows world, to have to know the exact network path (UNC) – like \\server\share\homes\mary – where they have rights, and type that UNC 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. In this example, when Mary granted you rights in subfolder C, MyDrives also granted the absolute minimum rights to allow you to traverse folders A and B. You can't see any other contents in those folders; you can only see that the folders themselves exist. We call these rights "Pass Through Folder".
Naturally, if you use a tool other than MyDrives to grant rights, our special "Pass Through Folder" rights won't be created.
Continuing with the current example, suppose Mary drags subfolder C to somewhere else on her M: drive. You still have "Pass Through Folder" rights 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" rights in the intervening folders to allow you to browse to it.
To fix this problem, MyDrives has the "Fix Orphans" button. If something has gone wrong with the "Pass Through Folder" rights on a drive, run Fix Orphans. MyDrives will examine the entire structure (starting in the folder you are sitting in), looking for "Pass Through Folder" rights that don't lead anywhere, or other rights that don't have "Pass Through Folder" rights leading to them.
Be aware that, because it has to examine the rights on every folder, it will take a long time on complex structures.
MyDrives normally hides "Pass Through Folder" rights. To see them, in the Manage Rights window, tick the "Advanced Options" box. A box called "Show 'Pass Through Folder'" will appear. Tick this box.
MyDrives shows only explicit rights, i.e. rights actually granted in that folder. That means it can look like there are no rights at all, because nothing appears in the list. Nothing appears because all the rights in that folder have been inherited from the parent folder.
MyDrives doesn't show inherited rights for a couple of reasons. First, you can't do anything with them; you can't remove them or modify them. You can only remove or modify the rights wherever they were granted. Second, they would clutter up the dialog and make it hard to find the rights that you can manage.
Sometimes, though, you may want to be able to see the inherited rights, perhaps to check that the rights are as you expect. To see them, in the Manage Rights window, tick the "Advanced Options" box. A box called "Show inherited rights" will appear. Tick this box.
If you are worried that the rights a user has in a folder are not what you intended, you can try viewing the "effective rights". This shows you not only the rights that have been granted in this folder, but the rights that the users actually have. To see them, in the Manage Rights window, tick the "Advanced Options" box. A box called "Show effective rights" will appear. Tick this box.
Be aware that MyDrives will only show the effective rights for users who are explicitly granted rights in the folder. If you also want to see what effective rights people are inheriting in this folder, also tick the "Show inherited rights" box.
A "share" is a Windows way of making a resource available on the network.
Windows treats the root of a share as a special circumstance. If you modify the rights at the root of a share, no matter how trivially, Windows will warn you that it will replace all rights in the entire directory structure below!
Imagine if you did this at the root of the share for all the M: drives. All the rights every single user had set, plus all the normal rights 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 rights at the root of a share.
Windows rights are built from 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 rights have quite obscure purposes; it would be very difficult to construct rights that did what you intended if you had to grant these individual building blocks. That's why MyDrives normally grants only the three most-used combinations: Read-Only; Read, Write and Delete (Change); Filestore Administrator (Full Control). Each of these will set the necessary individual building blocks.
Some of these rights 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 rights come in "Allow" and "Deny" flavors. So you can, for example, grant "Deny Full Control". "Deny" rights are extremely tricky to use. They trump all other rights, 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 right always wins, but also denying Full Control actually means denying every one of the individual building blocks that make up Full Control, thereby denying everything. Because these rights are so hard to use successfully, and because anything you want to do can be done without resorting to denying, MyDrives will only grant "Allow" rights. It will, however, display "Deny" rights that have been granted using a different method.
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 apply "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 building blocks 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 right 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 rights 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?
Intuitively, you expect things to be hidden from you if you don't have rights to them. But in the Microsoft world, if you have the List Folders individual building block, 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 rights to do anything with.
This causes a lot of problems. Merely protecting something from further access isn't always sufficient; sometimes even the name can be sensitive. 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 rights for each object in that folder and only show you those to which you have further rights. 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 rights to see the contents of the folder and filter them out. So although you can still grant these rights, when Access-Based Enumeration is enabled, they simply won't work.