Easy Napp-IT SMB/CIFS Share Permission Management

[K D]

I struggled to find the right way to set the permissions on a set of SMB Shares for the past 2 days. When right clicking the folder and setting permissions, it was only setting the folder permissions and not the share permissions. I was setting the permissions based on AD groups and not users. The pro extension evalutation initially said 30 days and suddenly it showed expired after a few hours of the server being online. I had almost given up and was thinking of switching to FreeNAS when It clicked.

I remembered reading somewhere that Solaris simulates a windows 2003 server for SMB/CIFS. That combined with the constant reminder that the ACL system is similar to windows, I finally figured it out.

Microsoft Management Console to the rescue. Open a MMC with a shares management console. With that I could update both Share permissions as well as folder permissions.

This is probably not news to a lot of you folks, But I couldn't find a clear way to do this over several days of searching.

Here are the steps I followed to get my sharing working. Hope this helps others.

1. In Napp-IT GUI, Join Windows Domain.
2. Map root to a Windows Domain Administrator.
3. In Windows, Open MMC, Add a Shared Folders Snap-In
   
   
4. Now, You can see all your SMB/CIFS shares and manage permissions
   

 

[gea]

Linux or Unix Systems with SAMBA use Unix UID users and GID groups as reference together with traditional Unix permissions like 755. When they add ACL, they usually add Posix ACL. If you are coming from the Linux/Unix World the Solarish NFSv4 ACL and the whole permission thinking of the Solaris SMB server is a little strange.

If you are a Windows user, where permissions settings are defined by the ntfs filesystem options with host dependent Windows SID as reference, the fine granular permission settings and special SMB groups that are more universal than Linux/Unix uid groups (for example Windows groups can include groups as group members.), the Unix/SAMBA thinking is strange and the Solarish SMB server with its NFSv4 ACLs behaves quite identical to a Windows server especially as it uses Windows SID identifiers in an AD environment what gives you the option to backup/ restore a filesystem to another Solarish system that is an AD member with all permissions intact.

The usual way to set SMB permissions on Solarish is to use Windows. Simply connect as user root or an admin user to set ACL on files with all Windows options and inheritances available. If you want to set share permissions, SMB connect to Solaris as a user that is a member of the SMB group administrators, open Computer management on Windows and connect to the Solarish server. You can then set share permissions or check for connected users or their open files.

There is mainly one difference between Windows and Solarish and this affects deny rules. Windows take care first about deny rules than allow rules while Solarish respects order of rules similar to firewall rules. So if you want to set deny rules you must set them on Solarish.

Another item is root/admin access. While root on Solarish has always full access even without a specific ACL rule, a Windows admin has only access with a permission rule. Without he must first set an according rule (this is always possible, optionally after a take ownership). So for backups or a global recursively change of permissions, Solarish is more flexible and this is where

the napp-it ACL extension is intended to use:
- reset all permissions recursively ex to everyone=modify (this is a free option)
- set proper deny rules
- set ACL without a Windows machine

If you only want to setup very special ACLs on Solarish rarely, you can use a 2 day eval key from napp-it.org that you can order online when needed.

 

[K D]

Thanks @gea.

 

[K D]

On an unrelated question, Is it OK to share the same dataset via NFS and SMB at the same time?

 

[gea]

Depends
I do this always on my All-in-Ones to access ZFS snaps for VM Copy/Move/Backup via Windows "Previous Versions"

Problem is permissions. For NFS3 that comes without authentication or authorisation and where file uid of new files depend on platform (nobody or client uid) this works usually only with an ACL rule like everyone@=modify and aclmode=restricted (hinders NFS to modify permissions) and possible NFS restrictions via client ip and SMB restrictions via share permissions or firewall rules.

For NFS4 you may coordinate permissions via idmapping or an Windows AD server with Unix extensions.