Napp-IT and SMB Issues

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

K D

Well-Known Member
Dec 24, 2016
1,439
320
83
30041
EDIT : Updated the title and added more information.

Original Question :
--------------
Is it possible to restart SMB service in omnios remote from a Windows server?

I am using AD groups to set share permissions for my SMB shares. If the domain controller is not available when Napp-it VM starts then all the share permissions are reset to "Everyone". I have to go in and update all permissions manually and then restart the SMB service to get back to my desires state.

I'm working on writing a set of powershell scripts that will set the share permissions from a Windows server. I still have to login to napp-it and restart the service manually. Is there anyway to send a remote signal to the napp-it VM and have it restart the service?
-------------

I see this error repeating in the Console. My DC is online and has no errors recorded. All other systems seem fine. I have no idea how to troubleshoot this issue. Napp-It resets all SMB share permissions to "Everyone". Initially I thought that it was because the DC was not available when NApp-It booted up but that doesnt seem to be the case.

Paging @gea

1.png
 
Last edited:

gea

Well-Known Member
Dec 31, 2010
3,161
1,195
113
DE
SSH would be an option for remote management.

about the share permissions.
what is your OS? I have heard of such problems with an earlier version of OmniOS, not with current stable.
 

K D

Well-Known Member
Dec 24, 2016
1,439
320
83
30041
Running OmniOS 5.11 (omnios-r151022-f9693432c2) with Napp-It 17.06free.
 

gea

Well-Known Member
Dec 31, 2010
3,161
1,195
113
DE
I have not seen this on current 151022 but I must say, I only use share permissions to temporary reduce access ex to readonly. Normally I use file permissions as this is the only way to backup/restore with permissions intact.

The share permissions on Solarish for a share ex tank/vm are permissions to the share control file /tank/vm/.zfs/shares/vm that is created when you share the fs the first time. This should survive a reboot and when you use AD credidentials without the AD connected, you should have no access due unknown users.

Without a dedicated mapping, Solarish use ephemeral (temporary/session) mapping to map AD accounts (Windows SID) to Unix UID/GID (in the end ZFS is a Unix filesystem, Sun did a hard job to make it ntfs alike). An option may be a fixed mapping (with idmap) to assign a Windows user/group definitely to a Unix UID/GID to have always a defined setting.
 
Last edited: