If you have been managing rights on an MWS drive for some time, you're probably familiar with the basic NetWare rights and how they work. Windows rights are completely different.
Note that in Windows they are called permissions rather than rights.
The permissions themselves are different. In NetWare, there were only 7 rights you could choose from: Read, Write, Create, Erase, Modify, File Scan, and Access Control. Aside from Modify and File Scan, these were reasonably self-explanatory.
In Windows, there are a lot more (between 13 and 19, depending what you count). 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 continue to present you with a choice of three categories: Read-Only; Change (i.e. read/write); and Full Control (i.e. Read, Write and Access Control). 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.
With Novell rights, when you applied them to a folder, all subfolders and files inherited those rights. In Windows, it isn't nearly so simple. There are effectively 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 equivalent to Novell inheritance and is the normal kind of inheritance we generally think about. The others would really only be required for very special purposes and are likely to be more confusing than useful. MyDrives will display the kind of inheritance a folder has, but will not offer you a choice of kinds of inheritance when granting permissions; it will always do "This folder, subfolders and files" except in special circumstances which we will talk about in a minute.
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 files 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".
In a normal Microsoft world, permissions operate very differently from what we are accustomed to. Imagine that in a particular folder (let's call it Folder1), you have List Folders/Read Files. However, in one of its subfolders (let's call it 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; this is how it would have worked in NetWare. Unfortunately, you would be wrong. You would still see the existence of Folder2. However, when you went to click on it, you would get an Access Denied message. What's going on?
Such a simple difference reveals a huge gulf between the Novell and Windows ways of thinking about rights. In the Novell world, things you don't have rights to see are automatically pruned from what is displayed to you. 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, because people can see it, they assume they have permissions to it, so they may try to open it. This results in the server having to record an unauthorized access attempt, which means there will be so many of them that it becomes impossible for the administrator to see whether there were any genuine unauthorized access attempts.
Microsoft have apparently decided that this is a problem and have recently introduced a new feature to try to resolve it. This is called Access-Based Enumeration. The idea here is that when you click on a folder (i.e. attempt to access it), 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 an attempt to approximate the way NetWare has always done it.
However, it has one significant side effect: if you want to give people the ability only to see the existence of files, you can't. This is because to do so, you would have to grant List Folders/Read Files but grant it 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 the Windows interface will still allow you to grant these permissions, when Access-Based Enumeration is enabled, they simply won't work.
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. When you run MyDrives and try to map to that user's M: drive, you will be told that you don't have permissions to see it. Why?
In the Novell world, if you have rights in a subfolder, you can implicitly see all the intervening folders to allow you to traverse from where you are to where you have rights. You can't see the contents of any of the intervening folders where you have no rights, but you can at least see enough to get you where you're going. 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, and type that UNC exactly, rather than being able to start and 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 for this problem.
To get around it, 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". They are granted with unusual inheritance, "This folder only", which means they are not inherited at all. So for each folder between the place where the user is likely to begin browsing and the folder where they actually have permissions, we must grant "Pass Through Folder" individually.
Naturally, if you use a tool other than MyDrives to grant permissions, our special "Pass Through Folder" permissions won't be created.
Also, if you move a folder by dragging and dropping it somewhere else, unlike under Novell, even its (supposedly) inherited permissions will go with it. You will therefore probably cause this problem -- your users will be unable to traverse the intervening folders to the folder where they do have permissions. Consider the current example. Suppose the user drags subfolder C to somewhere else on their M: drive. You now have "Pass Through Folder" permissions in folders A and B, but they don't lead anywhere useful, because folder C is gone. And wherever it was dropped, it's unlikely that your users are going to happen to have "Pass Through Folder" permissions in the intervening folders to allow them 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.
Normally, a folder inherits permissions from its parent. It can also have additional permissions expressly granted in it, which would in turn also be inherited by lower folders.
In Windows, there is a problem if you want to grant a user more restricted permissions than they have in a parent folder (for example, a user may have Change in one folder, but in a lower folder you may wish to grant them only Read-Only). Windows does not handle this as you might expect. When you grant Read-Only in the lower folder, that folder continues to inherit from its parent without the new explicit permissions overriding any inherited permissions for the same user. So even though you have granted Read-Only, the user also continues to inherit Change, which is clearly not what you wanted.
The way Windows handles this is by blocking ALL inherited permissions from the parent. Even if you wish to reduce the permissions of only one user, Windows cannot block inheritance for just that one user; it has to block them for everybody.
MyDrives is aware of this problem and handles it automatically. If you grant permissions to a user which amount to less than the permissions they inherit from a higher folder, MyDrives will automatically block inheritance, and then create new explicit permissions grants for all the permissions which would have been inherited from higher folders, except the user whose permissions you are reducing. It also grants the new reduced permissions to the user as you intended in the first place. This can be a bit surprising because, even if you were only granting rights to one user, lots of them may suddenly appear in the MyDrives window. This is just permissions that were previously inherited being made explicit.
This does mean that when you modify the permissions granted to higher-level folders, these changes only ripple down until they hit a folder where inheritance is blocked.
It also means that if you change your mind, and no longer require reduced permissions for a particular user, there needs to be a way for you to revert to inheriting permissions from above. You could delete the permissions explicitly granted, but this would just mean nobody would have any permissions; it wouldn't reconnect the folder to the normal flow of inheriting permissions. MyDrives therefore includes the "Resume Inheriting" button. Clicking this button will remove the expressly granted permissions, and remove the inheritance block, thereby allowing inherited permissions to flow through again.
If the Resume Inheriting button is grayed out, that means the current folder is already inheriting permissions from above and therefore has no need to revert.
There isn't anything wrong with granting reduced permissions, but it can make it harder to understand what permissions people have. (Also, it may not work as you expect: If you reduce a particular user's permissions, but they also are a member of a group which has been granted permissions, their final permissions will be the two sets of permissions added.) It is generally better practice to organize your folders so that you don't have to reduce permissions.
On a Novell server, when you change rights, it happens effectively instantly, because the server calculates rights for you. In Windows, whenever you modify permissions, Windows will examine the permissions of every folder (and file!) in the entire substructure of the folder where you are sitting and made the necessary changes. The important thing to be aware of is that it is your computer that makes the changes. Therefore, for a complicated structure, or if there are a lot of files, it can take a very long time. This is normal and can't be avoided.
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.