OmniOSce and Napp-It ACL Settings

[armouredking]

So giving OmniOS/Napp-It a try and running into real bugbears of problems. Most of the threads I've googled for are about permission setting, but I don't feel mine is in the same vein. These look more like bugs.

So I have setup OmniOS with Napp-It by USB install for OmniOS, setup a pfexec user at install, setup networking after reboot, install latest updates, then installed Napp-It via the pfexec user. Open up the browser, point to the address, and Napp-It setup completed. Can login and do stuff. Up to this point all is well.

Trying to setup shares however it seems like permissions are broken. In order to ensure the best possible scenario, I have created a blank zfs filesystem environment (auxtank/test) excluding the data that already exists. I wanted to make sure no permission problems could possibly be here by starting with a blank slate.

Start SMB sharing on auxtank/test. I have the following settings:

ACL of folder /auxtank/test
drwxrwxrwx+ 6 root root 6 Feb 3 18:44 (777)
 ACL   User/ Group   acl   acl-set   details   inheritance   type   option 
                               
 0   user:root   rwxpdDaARWcCos   full_set   rd(acl,att,xatt) wr(acl,att,xatt,own) add(fi,sdir) del(yes,child) x, s   file,dir   allow   delete 
 1   everyone@   rwxpdDaARWc--s   modify_set   rd(acl,att,xatt) wr(att,xatt) add(fi,sdir) del(yes,child) x, s   file,dir   allow   delete 

ACL of SMB share test (/auxtank/test/.zfs/shares/test)
-rwxrwxrwx+ 1 root root 0 Feb 3 18:37 (-777)
 ACL   User/ Group   acl   acl-set   details   inheritance   type   option 
                               
 0   everyone@   rwxpdDaARWc--s   modify_set   rd(acl,att,xatt) wr(att,xatt) del(yes,child) x, s   folder only   allow   delete

At this point, everything is still working without issue. I can browse the share by going to \\omniosce\test and create folders, add files, etc. No problems.

Okay, time to make things more limited. Per the directions here I want to make it so that I can browse the share, but cannot edit files or delete. READ ONLY. So I go to ACL onSMB Shares and click on acl-set to change the feature from modify_set to read_set. Set property.

Now this happens:

ACL of SMB share test (/auxtank/test/.zfs/shares/test)
-r--------+ 1 root root 0 Feb 3 18:37 (-400)
 ACL   User/ Group   acl   acl-set   details   inheritance   type   option 
                               
 0   user:root   r-----a-R-c---   read_set   rd(acl,att,xatt)    folder only   allow   delete

everyone@ is gone. It is replaced by my read_set which I wanted, but user/group has changed to user:root. I cannot do anything with the share. Okay then, ++ add trivial ACL@, select everyone@ and read_set. Set property. Now I have:

ACL of SMB share test (/auxtank/test/.zfs/shares/test)
-r--r--r--+ 1 root root 0 Feb 3 18:37 (-444)
 ACL   User/ Group   acl   acl-set   details   inheritance   type   option 
                               
 0   user:root   r-----a-R-c---   read_set   rd(acl,att,xatt)    folder only   allow   delete 
 1   everyone@   r-----a-R-c---   read_set   rd(acl,att,xatt)    folder only   allow   delete

Delete user:root line. Now I have:

ACL of SMB share test (/auxtank/test/.zfs/shares/test)
-r--r--r-- 1 root root 0 Feb 3 18:37 (-444)
 ACL   User/ Group   acl   acl-set   details   inheritance   type   option 
                               
 0   everyone@   r-----a-R-c---   read_set   rd(acl,att,xatt)    folder only   allow   delete

Well, this is what I wanted. Had to go around my elbow to get there, but here we are. Seems bugged. Oh but wait. I still can't access the share you say? Correct. I cannot access the share. In order to get access back to the share, I have to use at a minimum an acl-set of modify_set. No others will work. So... no read only? I can only have modify permissions or full permissions, no ability to just read?

On another note, I also attempted to set stuff manually with the field next to acl-set, acl. This also appears to be a bug. In the popup window, I see the following:

Change property auxtank/test/: acl

 [ ] (r) list_directory 
 [ ] (w) add_file
 [ ] (x) execute
 [ ] (p) add_subdirectory
 [ ] (d) delete
 [ ] (D) delete_child
 [x] (a) read_attributes
 [ ] (A) write_attributes
 [x] (R) read_xattr
 [ ] (W) write_xattr
 [x] (c) read_acl
 [ ] (C) write_acl
 [ ] (o) write_owner
 [ ] (s) synchronize

(r) list_directory is not selected, there is no check mark in the box. Yet, the acl field shows it there:

ACL of SMB share test (/auxtank/test/.zfs/shares/test)
-r--r--r-- 1 root root 0 Feb 3 18:37 (-444)
 ACL   User/ Group   acl   acl-set   details   inheritance   type   option 
                               
 0   everyone@   r-----a-R-c---   read_set   rd(acl,att,xatt)    folder only   allow   delete

Both lower and upper case R are listed. I ran across this bug? when attempting to use the "write_set" acl-set ( which does not natively have r selected ) and attempting to select it. It doesn't work.

-----

For completion sake, here are the same notes from command line:

supervisor@omniosce:/auxtank$ ls -V
total 72
drwxrwxrwx+ 13 1000     1000          13 Feb  3 17:49 backups
              user:root:rwxpdDaARWcCos:fd-----:allow
              everyone@:rwxpdDaARWc--s:fd-----:allow
drwxrwxrwx+  6 root     root           6 Feb  3 18:33 filerun
              user:root:rwxpdDaARWcCos:fd-----:allow
              everyone@:rwxpdDaARWc--s:fd-----:allow
drwxrwxrwx+  6 root     root           6 Feb  3 18:44 test
              user:root:rwxpdDaARWcCos:fd-----:allow
              everyone@:rwxpdDaARWc--s:fd-----:allow

From the "ACL on folders" screen I can select acl-set and update such that stuff updates without anything like the bugs? of the "ACL on SMB Shares":

ACL of folder /auxtank/test
drwxr--r--+ 6 root root 6 Feb 3 18:44 (744)
 ACL   User/ Group   acl   acl-set   details   inheritance   type   option 
                               
 0   user:root   rwxpdDaARWcCos   full_set   rd(acl,att,xatt) wr(acl,att,xatt,own) add(fi,sdir) del(yes,child) x, s   file,dir   allow   delete 
 1   everyone@   r-----a-R-c---   read_set   rd(acl,att,xatt)    file,dir   allow   delete

The everyone@ group does not change into user:root like what happens on "ACL on SMB Shares". The (r) list_directory option under acl actually shows up as checked. Unfortunately that's where the good news ends:

supervisor@omniosce:/auxtank$ ls -V
total 72
drwxrwxrwx+ 13 1000     1000          13 Feb  3 17:49 backups
              user:root:rwxpdDaARWcCos:fd-----:allow
              everyone@:rwxpdDaARWc--s:fd-----:allow
drwxrwxrwx+  6 root     root           6 Feb  3 18:33 filerun
              user:root:rwxpdDaARWcCos:fd-----:allow
              everyone@:rwxpdDaARWc--s:fd-----:allow
drwxr--r--+  6 root     root           6 Feb  3 18:44 test
              user:root:rwxpdDaARWcCos:fd-----:allow
              everyone@:r-----a-R-c---:fd-----:allow

This is the everyone group, it has read_set. I can no longer list the directory contents as supervisor from command line:

supervisor@omniosce:/auxtank$ ls -V test
test/New folder: Permission denied
test/more: Permission denied
test/test: Permission denied
total 0

Returning everyone to modify_set:

supervisor@omniosce:/auxtank$ ls -V test
total 3
drwxrwxrwx+  2 michael  staff          2 Feb  3 18:44 New folder
              user:root:rwxpdDaARWcCos:fd----I:allow
              everyone@:rwxpdDaARWc--s:fd----I:allow
drwxrwxrwx+  2 michael  staff          2 Feb  3 18:38 more
              user:root:rwxpdDaARWcCos:fd----I:allow
              everyone@:rwxpdDaARWc--s:fd----I:allow
drwxrwxrwx+  2 michael  staff          2 Feb  3 18:38 test
              user:root:rwxpdDaARWcCos:fd----I:allow
              everyone@:rwxpdDaARWc--s:fd----I:allow

How about specifying the user directly?

ACL of folder /auxtank/test
drwxr--r--+ 6 root root 6 Feb 3 18:44 (744)
 ACL   User/ Group   acl   acl-set   details   inheritance   type   option 
                               
 0   user:root   rwxpdDaARWcCos   full_set   rd(acl,att,xatt) wr(acl,att,xatt,own) add(fi,sdir) del(yes,child) x, s   file,dir   allow   delete 
 1   user:supervisor   r-----a-R-c---   read_set   rd(acl,att,xatt)    file,dir   allow   delete 
 2   everyone@   r-----a-R-c---   read_set   rd(acl,att,xatt)    file,dir   allow   delete

supervisor@omniosce:/auxtank$ ls -V test
test/New folder: Permission denied
test/more: Permission denied
test/test: Permission denied
total 0

Why? Why does the read permissions not work?

 

[gea]

Propably because you need the execute (readx) permission.

btw
Connect the SMB share from Windows as root to setup file/folder permissions and set ACL from Windows. This is the easiest way (you should only avoid to set deny rules from Windows as Solarish processes them based on order while windows processes them always first).

You can also set share permissions from Windows when you SMB connect as a user that is a member on the Solaris SMB group admins. Then start computer management and connect to OmniOS.

 

[armouredking]

Okay, readx seems to work. That page on the napp-it site just needs an update then since this:

You want to reduce all permissions to read without changing file or folder ACL (and keep peter=full)
set share-level ACL to peter=full
add share-level ACL everyone@=read

Share level ACL is like a gatekeeper that can reduce all permsisions independently from files or folders

...is not accurate.

 

[gea]

I have updated this to
add share-level ACL everyone@=read (readx when set on Solarish)

On Windows everyone=read is enough

 

[armouredking]

Thanks for the help. Any idea about the menus / ACL SMB Share menu issues? Or is it not worth the bother because of using Windows ACL?

Currently using Home version of Windows as my daily driver so difficult to make changes, was able to circumvent a little bit by adding the Windows user mapping to admin/root and adding the permissions I wanted in Napp-It and changing from the MMC for Shared Folders. So many settings limited on Home, will probably setup a Pro VM just for RDP and Share Management on Unraid when I get the chance.

 

[gea]

ZFS is a Unix filesystem with UID/GID credidentials.
Solaris added Windows SID, Windows compatible SMB groups and nfs4 ACL that are beside processing of deny rules quite identical to Windows and the ACL options of ntfs.

Beside the deny item there is no difference if you set ACL from Windows or locally on Solarish (Windows Home remote ACL options are limited)

Idmapping in Solarish is to map AD users to local Unix users. Do not map a Unix user to another Unix user.

 

[armouredking]

I understood that part, what I meant was about the menus and how they don't behave. ACL on Folders works fine, no issues. ACL on Samba does not. The menu randomly changes the username and group if you attempt to modify them from Napp-It, and some of the selectors don't work in the popup menu for selecting manual permissions.

I was able to set the permissions via Windows Home edition by simply adding all the users I wanted to edit from Napp-It and then editing the permissions via MMC. Unfortunately Home edition is missing some features though so I was hoping to use Napp-It's more indepth management until I could get a Pro or Server edition running again.

Is the behaviour of the ACL on Samba supposed to be different in Napp-It menus than ACL on files? It has the same interface, but it does not behave the same way. That's what I mean by bugs.

See pictures here of issue difference between the ACL menus: Bugs

 

[gea]

SAMBA??, this is another SMB server
I suppose you mean setting ACL from Windows via SMB

Setting ACL can be a littly tricky especially as Windows has a different philosophy than Unix and the filesystem ntfs that defines Windows ACL is different to ZFS, a Unix filesystem. While Solarish offers most of ntfs behaviours its only similar not identical. The same with user groups. Windows SMB groups offer a advanced behavior over Unix/Linux groups. This is why Sun added SMB groups to Unix gid groups to improve Windows compatibility.

On Windows, an admin needs an ACL that gives him access. Without admin has no access until he added the ACL that allows him (admin can do this on Windows as root can on Unix). I love this on Unix as root can do backups even if a owner=creator of a file/folder removed the admins.

On Unix, the owner or root have a "hidden" full access but not in any case.
So look what you have done.

You have a single permission of everyone=full and reduce to everyone=read what means that you remove the full permission from yourself. This can work or not even as root.

The best outcome is if you want to set permissions for other users as root is to keep the root=full intact. In this case everything will work from Windows or locally on Unix when ACL modification is done as root or in general, keep yourself=full and reduce the permission of others (Do not lockout yourself)

 

[armouredking]

No, I meant what I said. Please see the pictures in the imgur library in the link at the end of my last post.

SMB is what the feature is called in the Napp-It menu. The menu is literally "ACL of SMB share <name$>" in the title.