napp-it can't setup local groups for acl

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

lem_urist

New Member
Jul 3, 2025
3
0
1
Hello everyone, I'm trying napp-it on OmniOS on my NAS but I'm getting frustrated at the ACL settings. Currently I want to share a ZFS Subvolume via NFS setting up read/write permissions for a local Unix group. If I'm understanding this correctly, I have to map this group to a SMB group in order to use the ACL functioning, so I setup the idmapping like shown:1751542201622.png

Then I tried to setup the local group ACL but I can only set it up for the default power users => staff mapping:

1751546585387.png

Am I doing something wrong? I've also tried to create an SMB group with no change in the behaviour whatsoever. I'm using Napp-It SE 25.06 (just updated from 25.01), I don't know if this happens on older versions of napp-it.
 

gea

Well-Known Member
Dec 31, 2010
3,490
1,373
113
DE
NFS access restrictions are not so easy. With NFS3 there is no authentication or authorisation beside some host/ip based basic ones. Depending on server or client, a file is written under the uid of a user or as nobody. NFS4 offers authentication or authorisation but is not as easy to implement.

SMB especially the OmniOS kernelbased one does not use uid/gid as access reference but Windows SID. A mapping between Windows and Unix accounts can help to coordinate SMB and NFS access (beside the cases where it cannot work ex due NFS access as nobody):

In the end, consider your use case. NFS is ok for fast anonymous access, in all other cases SMB is superiour regarding features or usability. As the OmniOS SMB server uses Windows SID and supports Windows SMB groups, use a Windows client. SMB connect as root (or a user mapped to root, this is the only Windows-Unix mapping you want with SMB) and set ACL remotely. This is different to SAMBA where you must set permissions locally with proper settings in smb.conf. OmniOS SMB is much easier to configure remotely.

btw
napp-it version does not matter.
 

lem_urist

New Member
Jul 3, 2025
3
0
1
NFS access restrictions are not so easy. With NFS3 there is no authentication or authorisation beside some host/ip based basic ones. Depending on server or client, a file is written under the uid of a user or as nobody. NFS4 offers authentication or authorisation but is not as easy to implement.

SMB especially the OmniOS kernelbased one does not use uid/gid as access reference but Windows SID. A mapping between Windows and Unix accounts can help to coordinate SMB and NFS access (beside the cases where it cannot work ex due NFS access as nobody):

In the end, consider your use case. NFS is ok for fast anonymous access, in all other cases SMB is superiour regarding features or usability. As the OmniOS SMB server uses Windows SID and supports Windows SMB groups, use a Windows client. SMB connect as root (or a user mapped to root, this is the only Windows-Unix mapping you want with SMB) and set ACL remotely. This is different to SAMBA where you must set permissions locally with proper settings in smb.conf. OmniOS SMB is much easier to configure remotely.

btw
napp-it version does not matter.
I'm planning to use this dataset as a shared folder for Linux clients. I wanted to setup a read-write permission for a local Unix group (GID 2001, the same as the hosts) and as far as I've read, it is better to do it with the SMB-Unix mappings. I do not plan on sharing this folders for Windows hosts, or at least it is not the main use case.

So I've tried setting up the permissions using chgrp to change the group of the dataset's mouting point and so far so good. I thought there would be a more elegant solution to this.

So what should I do? Should I setup the permission like this? How should I setup the ACL for a local Unix group?
 
Last edited:

gea

Well-Known Member
Dec 31, 2010
3,490
1,373
113
DE
I would use SMB only, also for Linux/OSX/Unix clients and set ACL remote from Windows.
For Linux an additional item is the incompatibility of the Posix ACL model of Linux to the ntfs/nfs4 ACL model in Windows or Solaris
 

MargoBillings

New Member
Jul 8, 2025
1
0
1
I'm planning to use this dataset as a shared folder for Linux clients. I wanted to setup a read-write permission for a local Unix group (GID 2001, the same as the hosts) and as far as I've read, it is better to do it with the SMB-Unix mappings. I do not plan on sharing this folders for Windows hosts, or at least it is not the main use case.

So I've tried setting up the permissions using chgrp to change the group of the dataset's mouting point and so far so good. I thought there would be a more elegant solution to this.

So what should I do? Should I setup the permission like this? How should I setup the ACL for a local Unix group?
You should see acl in the mount options. If not, you need to edit /etc/fstab.
Or closer, If you are using ZFS: use zfs set aclinherit=passthrough and aclmode=passthrough.
This is absolutely useful.
 

lem_urist

New Member
Jul 3, 2025
3
0
1
I would use SMB only, also for Linux/OSX/Unix clients and set ACL remote from Windows.
For Linux an additional item is the incompatibility of the Posix ACL model of Linux to the ntfs/nfs4 ACL model in Windows or Solaris
I've rolled up a W11 machine and it works wonders, however the immense majority of machines, including desktop computers, are running some sort of Unix and it's a little bit annoying setting up ACLs like this, I guess I could do the same with OmniOS' chmod right? Or do I lose something not modifying them from Windows?

You should see acl in the mount options. If not, you need to edit /etc/fstab.
Or closer, If you are using ZFS: use zfs set aclinherit=passthrough and aclmode=passthrough.
This is absolutely useful.
I am in fact using ZFS, I don't know if you can use any other FS on OmniOSCE.

The thing is, it really works like gea says, but I would like to know if the ACL extension allows for other groups apart from power users to set ACLs up. I tried to create an SMB Group, but the extension only lets me add permissions for Power Users. My evaluation period is out and I'm comfortable enough to set this kind of permissions by CLI, so if there is no difference from setting them up from Windows, I think I'm gonna use that.

Other than that, I have to say the application is formidable. Its integration with a wonderful storage system like OmniOS makes it a great option to set-up a NAS/SAN like in my case. Many thanks to gea and all the napp-it team (IDK if its just gea or there's more people involved, many thanks to them anyway).
 

gea

Well-Known Member
Dec 31, 2010
3,490
1,373
113
DE
I've rolled up a W11 machine and it works wonders, however the immense majority of machines, including desktop computers, are running some sort of Unix and it's a little bit annoying setting up ACLs like this, I guess I could do the same with OmniOS' chmod right? Or do I lose something not modifying them from Windows?


I am in fact using ZFS, I don't know if you can use any other FS on OmniOSCE.
The Solaris/OmniOS SMB server is based on nfsv4 ACL. You can set nfsv4 ACL locally via chmod but not remotely from a Linux client as Linux only supports the much simpler (and incompatible) Posix ACL model. Modifying nfsv4 ACL via chmod is not as easy, using Windows that is build to modify ntfs ACL (that are quite identical to nfsv4 ACL) is much easier, New Solaris ACL Model - Oracle Solaris Administration: ZFS File Systems

Solaris and the Solaris fork are build around ZFS without the option to use another fs seriously.

btw
care about the ZFS properties acltype (nfsv4) and aclmode, aclinherit (set to passthrough for a Wndows SMB alike behaviour)
 
  • Like
Reactions: lem_urist