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.
The purpose of MyDrives' rights management feature is to save you from having to understand the complexity of Windows permissions "under the hood". But if you want to know more, see The Not-So-Basics.
There is a problem if you want to grant a user less permissions 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 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 Read, Write and Delete.
The only way Windows can reduce permissions is to block 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.
If you must do it, MyDrives handles it for you. If you click Stop Inheriting, or grant permissions which are less than what the user inherits from the parent folder, MyDrives will warn you, block inheritance, and then create new explicit permissions for everything that would have been inherited. This can be a bit surprising because lots of permissions may suddenly appear. These are just permissions that were previously inherited being made explicit.
Avoid using this. Imagine that you now want to create a new Filestore Administrator, from the 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, the folder where you are doing it 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. 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.
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 exact network path (UNC) where they have permissions, 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. 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.
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, a box called "Show 'Pass Through Folder'" will appear. Tick this box if you want to see them (but don't forget to untick it when you are done!).
MyDrives shows only explicit permissions, i.e. permissions actually granted in that folder. That means it can look like there are no permissions at all, because nothing appears in the list. Nothing appears because all the permissions in that folder have been inherited from the parent folder.
MyDrives doesn't show inherited permissions for a couple of reasons. First, you can't actually do anything with them; you can't remove them or modify them. You can only remove or modify the permissions wherever they were granted. Second, they would clutter up the dialog and make it hard to find the permissions that you could manage.
Sometimes, though, you may want to be able to see the inherited permissions, perhaps to check that the permissions are as you expect. If you tick the "Advanced Options" box, a box called "Show inherited rights" will appear. Tick this box if you want to see them (but don't forget to untick it when you are done!).
If you are worried that the permissions a user has in a folder are not what you intended, you can try viewing the "effective rights". This shows you not only the permissions that have been granted in this folder, but the permissions that the users actually have. If you tick the "Advanced Options" box, a box called "Show effective rights" will appear. Tick this box if you want to see them (but don't forget to untick it when you are done!).
Be aware that MyDrives will only show the effective rights for users who are explicitly granted permissions 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 permissions at the root of a share, no matter how trivially, Windows will warn you that it will replace all permissions in the entire directory structure below!
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.
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 rights that did what you intended if you had to grant these individual building blocks. That's why MyDrives normally expects you to work with only the three most-used permissions: Read-Only; Read, Write and Delete (Change); Filestore Administrator (Full Control). Each of these will set the necessary individual building blocks.
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 building blocks 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 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 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?
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 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 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.