My discussion will be based on the following minimal scenario:
(box-01 is a Solaris 11.3 acting as a Windows 2000 Server)
The graphical interface of the (directory and files) unified ACL editor (Properties | Security) seems good to manage basic settings such as: List Folder Contents, Read & Execute, Modify and Full Control. But it is impossible to get the big picture at once, it may be confusing for handling inheritance and it mixes in more complex permissions sets. The point is: it should allow us to see the permissions for all names at once, it shouldn't have the confusing Read and Write options and it should have a more objective approach (other than the confusing dimmed or grayed out checkboxes alongside the Allow inheritable... checkbox) on the inheritance status. And on top of all this, by clicking on the checkboxes on a certain order (check Modify then clear Write, you would expect to be left with Read & Execute but you don't!) it's possible to mistakenly generate unwanted special permissions.
Unfortunately, the design of the Advanced option, entitled Access Control Settings is also bad because it adopts horizontal scrolling (which is terrible; they don't even persist the tedious adjustments of the listview columns that someone does in order to better see all the information without scrolling) instead of more concise graphical elements and filtering, or even a resize-able dialog, in order to really help an administrator do its job. Bottom line is it's also cumbersome as the basic one. Again, unfortunately, especially because Windows is so centric on ergonomics and GUI design. It's like this area has been greatly overlooked or treated with laziness (many out there could do a lot better than that...).
Still similarly to what I have done for Windows NT 4.0 (and before) let's initially focus just on the permissions sets that are displayed on the basic (Properties | Security) dialog.
The first thing to note is that the legacy permission flags (R, W, X, D, P and O) have all gone. They were replaced by other 13 (frequently even more confusing) flags which have no compact names but just descriptions and are only accessible after yet another click and more scrolling and a bunch more clicks. As you can see, a nightmare (I'm still not sure if they really wanted to discourage people or hide their mess, perhaps both, but there would be better ways, but, that's Windows!). In order to help put things in order we have the following 1-1 mapping between the each NFSv4 and Windows permission flag:
To help even more here is a mapping for the Windows 2000 basic permission sets dialog together with each flag setting, bor for the unnamed Windows flags and the UNIX NFSv4 ACLs (for simplicity here I'm intentionally omitting the name of the associated user or group that should be prefixed to each UNIX ACL and I'm also representing the 13 Windows flags as an ordered row resulting from a counter-clockwise rotation of 90°):
Full Control
+Modify +Read & Execute +List Folder Contents +Read +Write
rwxpdDaARWcCos:fd-----:allow
Modify
+Read & Execute +List Folder Contents +Read +Write
rwxpd-aARWc--s:fd-----:allow
Read & Execute
+List Folder Contents +Read
r-x---a-R-c--s:fd-----:allow
List Folder Contents
r-x---a-R-c--s:-d-----:allow
Read
r-----a-R-c--s:fd-----:allow
Write
-w-p---A-W---s:fd-----:allow
NOTE
The preceding series of ACLs is formatted in terms of directory permissions but the same translation applies to file permissions (except, of course, List Folder Contents) if you disregard the respective ACL inheritance flags (between both colons in my listing) which contains an f and/or d. For instance, the Full Control for a file is depicted by rwxpdDaARWcCos:-------:allow, but depending on the inheritance it may show a trailing I inheritance flag.
NOTE
If needed, the Add & Read permission set from Windows NT 4.0 (and before) must be manually created from the scratch by adding the following two permission sets to the desired user and directory:
r-x---a-R-c--s:f-i----:allow
rwxp--aARWc--s:-d-----:allow
Which, in other words, basically means:
Read & Execute for files and
Read, Write & Execute for directories (not their contents).
NOTE
As a variation of the Add & Read permission set above it could be interesting to have the possibility to add a folder just to a certain subtree root (or share) while all other permissions are inherited (as for giving read access to a group and so on). In that case, it's assumed (of course) that amongst the inherited permissions is the Full Control for the CREATOR OWNER identity. The permission that has to be added to the desired subtree root is:Well, beyond all the above, who knows, maybe someone can devise some useful and unanticipated sort of special access, but in general what's been seen is pretty much all about that.
r-xp--a-R-c--s:-------:allow
With the knowledge of this post, it's not necessary to resort to a Windows box in order to set meaningful permissions according to Windows by using its GUI editors. You can do it from a Solaris 11.3 shell by using chmod(1).
