SolarisCIFSPermissions

At this point this is a scratch pad page with some commands worth exploring

If you are running in workgroup mode this is fairly simple:

chmod 777 directory

Of course you probably want more complex than 777, but the permissions are simply your local users - manage like any other Unix permissions.

On a domain this gets more complicated. The users are mapped to local user accounts automatically (unless you set it not to do this automatically, if you have done that you probably understand everything covered here).

About my example:

• The ZFS is at pool1tbsas, a subdirectory of that is pool1tbsas/stever - This is what we'll be working with. This is set to sharesmb=name=stever
• My active directory user account will be stever @ bitshop.com
• We will use the "Domain Users" group as the only group we'll discuss.

NOTE: The users don't map to a local Solaris user until they attempt to connect: This means that you can't set permissions until after the user has tried to connect, i.e. this can be a hassle IMHO. You have to tell the user go try to connect, yeah, I know you got an error.. now let me fix it.. I understand WHY this is done this way, I don't have a suggestion to make it better without dumping all the users / creating them all, but it seems awkward. Too bad we can't just say this SID # gets these permissions - I'm not sure why ZFS wasn't implemented this way.. seems trivial to have just allowed a longer security id on the structure to match NTFS.

Once the user has connected you now need to find the mapping ID. For example lets say we're looking for the bitshop.com user stever:

idmap dump -n
......
winuser:stever@bitshop.com      ==      uid:2147483649

If you wanted to find the Domain Users group:

idmap dump -n
......
wingroup:Domain Users@bitshop.net       ==      gid:2147483650

So we now have a uid and a gid (user id and group id) in Solaris which map to these users, this id # is used for chmod.

Let's list permissions for the directory "stever". The command is "ls -V":

bitshop@zfs001:/pool1tbsas# ls -V
ls: invalid option -- V
Try `ls --help' for more information.
bitshop@zfs001:/pool1tbsas# /usr/bin/ls -V
-rw-r--r--   1 root     root     5 May 22 04:41 stever
            owner@:--x-----------:-------:deny
            owner@:rw-p---A-W-Co-:-------:allow
            group@:-wxp----------:-------:deny
            group@:r-------------:-------:allow
         everyone@:-wxp---A-W-Co-:-------:deny
         everyone@:r-----a-R-c--s:-------:allow

You'll notice "ls -V" gives an error, this is because the default ls is the gnu ls, not Solaris ls. argh. The fix is simple luckily, just point to ls in the other path and it works.

We'll need to change these permissions, let's start with 777 / everyone having full control, then we'll work are way back. For those from the windows world the OLD Unix permissions were simple, the first # is the users permissions (binary, 7=rwx, i.e. full control, read / write / execute permission). The second # is the group's permissions, the third is everyone. A single user and a single group owned the directory/file - So 777 is a quick way to say "Everyone:Full Control" or "cacls . /g everyone:f" if you're a cmd kind of guy.

bitshop@zfs001:/pool1tbsas# chmod 777 stever
bitshop@zfs001:/pool1tbsas# chmod A=everyone@:rwxpdDaARWcCos:fd:allow stever
chmod: invalid mode: `A=everyone@:rwxpdDaARWcCos:fd:allow'
Try `chmod --help' for more information.
bitshop@zfs001:/pool1tbsas# /usr/bin/chmod A=everyone@:rwxpdDaARWcCos:fd:allow stever

You'll notice that "chmod" gives an error. Same problem as above with ls. Fix is specify the path.

So what are our permissions now?



Not very surprising. Now we can get into some more complex permissions, let's add user stever @ bitshop.com and "Domain Users" group. For now we'll just say full control..

Some things say we can manage these permissions via windows, however when you click "Locations" the domain is not available as a choice for where to get users from (argh).



So we'll go back to Solaris and add these users manually. We'll add them with full control, then we'll manage them on windows to set the permissions however you desire (where you are probably more familiar with the tools):

bitshop@zfs001:/pool1tbsas# /usr/bin/chmod A+user:2147483649:rwxpdDaARWcCos:fd:allow stever
bitshop@zfs001:/pool1tbsas# /usr/bin/chmod A+group:2147483650:rwxpdDaARWcCos:fd:allow stever
bitshop@zfs001:/pool1tbsas# /usr/bin/ls -V
drwx---rwx+  4 2147483649 root           5 May 22 04:41 stever
    group:2147483650:rwxpdDaARWcCos:fd-----:allow
    user:2147483649:rwxpdDaARWcCos:fd-----:allow
         everyone@:rwxpdDaARWcCos:fd-----:allow

And back in Windows we now see:


We can now edit the permissions in windows. Of course you can continue adding as many users / groups as you need in Solaris.

CAUTION: I've been able to stop the share from being accessible to smbd / Solaris on boot / restart of the service - The permissions are slightly unclear what are needed - however the everyone user you probably don't want to completely remove. It appearntly requires SOME permissions although I can't find a document saying what is required. Realize that users that aren't specifically mapped will NOT be able to access the share, even though it's marked as "everyone".

My current belief on the minimum permissions to leave for "everyone" is:

• Read Attributes
• Read Permissions

If these 2 are checked the server seems to work ok.