Napp-in-One integrate into Domain

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

ARNiTECT

Member
Jan 14, 2020
92
7
8
I am trying to integrate Napp-it/OmniOS into my domain to share files & folders.

For years, I had been sharing files & folders from large virtual disks attached to a Windows Server VM (SBS2011). This was easy to set up, but I would like to take advantage of the benefits of sharing files & folders using SMB server from Napp-it.

I now have 2x ESXi hosts, 2x Domain Controllers and a File Server using Windows Server 2019. Domain clients & workgroup clients are using Windows 10 pro.
I can access the SMB shares from all domain and workgroup machines by name or IP, but the shares are not visible in Windows 'Network' folder.

What is the best practice for setting these up for Napp-it SMB shares in a Domain? what are typical mistakes to avoid?

Can Napp-it communicate with 2 domain controllers? The Primary DC1 is stored on the Napp-it NFS share, therefore the DC1 will start after the SMB server is started; but DC2 will be available from the other host. I would rather keep the primary DC1 on the more powerful host, I could move it to a local datastore to start before OmniOS, if this is more sensible, but then it wouldn't benefit from the features of ZFS.

In SBS2011, I managed shares and folder redirection etc. from vmdk drives attached to the server VM. Now I have separated DC, File Server and SMB server. Therefore, where should I manage file shares and folder redirection now, should this be from a Windows Server 2019 File Server role, or is this redundant and just use Napp-it and the DC to manage?

The VMs are currently like this:

Host 1 (ESXi 6.7U3 on USB) Xeon E-2278G/128GB
VMs on local SSD datastores:
- vCenter Server Appliance
- OmniOS r151034 / napp-it 20.01 pro
VMs on NFS shares from Napp-it:
- Domain Controller 1 (Windows Server 2019)
- File Server (Windows Server 2019)
- Servers: Veeam, media, etc (Windows 10 pro)
- Virtual desktops (Windows 10 pro)

Host 2 (ESXi 6.5U2 on USB) Xeon X3450/16GB
VMs on local SSD datastores:
- OmniOS r151034 / napp-it 20.01 pro
VMs on NFS shares from Napp-it:
- Domain Controller 2 (Windows Server 2019)
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
To join a domain: use menu Services > SMB > AD: join
What I do usually afterwards is to add an idmapping windows:administrator -> unix:root (Menu Users) to give the domain admin full permissions.

The join dialog offers to enter a primary and secondary ad. This is for Solaris. OmniOS only supports one AD

The AD server must be available on bootup. If not or if it disconnects, you must rejoin or restart the SMB service on OmniOS

After joining the Domain, Windows AD act as a master browser what makes all computers (OmniOS) visible under Network.

You can use Windows Computer Management to manage OmniOS/Solaris SMB.
For this SMB connect as a user that is a member of the SMB administrator group on OmniOS/ Solaris, open Computer Management and connect to OmniOS/Solaris (connected users, open files, share acl etc)
 

ARNiTECT

Member
Jan 14, 2020
92
7
8
Thanks gea,

I'll map an administrator to unix:root with full permissions.

Ok, I would prefer to not have to manually restart the SMB service, so I understand this means I need DC1 to start before OmniOS. To do this, I'll need to move DC1 off the OmniOS NFS share, options:
- swap hosts for DC1 & DC2
- put DC1 on a local Datastore
- deploy another OmniOS/Napp-it VM with a pair of drives mirrored (this might be a bit over the top). Is the napp-it pro license per host, or per VM?
- get rid of DC2 and use vSphere vMotion / HA for DC redundancy, I have no idea how to do this yet. Would OmniOS be ok with this HA type setup without dropping the SMB service?

I had issues with 'Master Browsers' last time I tried this, maybe it will sort itself out once everyone has joined the domain and it has had time to settle.

It sounds like using Windows 'Computer Management' can be done from the Windows Server 2019 Domain Controller and I don't need a File Server for file sharing and folder redirection etc, is this correct? I have just logged on using CM (OmniOS currently still on Workgroup) and I can see Shares, Open files, Users and Groups. I will keep the separate File Server anyway for other roles and with a vmdk attached as a repository for Veeam backups, to allow Windows Server to do deduplication.
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
- The napp-it Pro license is per server/VM but for this task napp-it free is ok
- a DC on local datastore is ok. If you need a backup, use Veeam. The backup AD can be on NFS.
- You should avoid to loosd connectivity to AD. After some time, you need to rejoin or restart SMB.
A short disconnect shoule be ok (I have not tested max timout)
- SMB Server/Computer management of OmniOS can be done also from from Windows 10.

Main concern should always be "keep it simple"

As an alternative for Veeam backup, you can use the very fast and simple Amazon S3 compatible storage services on OmniOS via minIO.
Dedup should only be a concern with serious dedup rates. Otherwise use larger or add some disks and enable lz4 compress. With a special vdev mirror for dedup, realtime ZFS dedup becomes now also an option as the RAM need is no longer a concern.
 

ARNiTECT

Member
Jan 14, 2020
92
7
8
DC1 on Host1 local datastore seems the simplest solution using my existing knowledge.

For Host2, I don't think I need OmniOS SMB to join the domain, which means DC2 can remain on the Host2 NFS. If I did want to join Host2 to the domain, then I would need to move DC2 to a local datastore and enter DC2 as the AD in Host2 OmniOS.

Perhaps there is a better solution leveraging vmware features such as vMotion, but my knowledge is limited here.

Veeam B&R 10 CE can backup to SMB and NFS, what is the advantage of using Amazon S3?
 

ARNiTECT

Member
Jan 14, 2020
92
7
8
Which option looks more sensible:

Host 1 Option A:

on Local SSD datastore:
- OmniOS-1 / napp-it 'free', pass-through: 2x Optane 900P 280Gb (mirrored), share as NFS back to ESXi sync:enabled

on OmniOS-1 NFS shares:
- Powerchute UPS appliance
- Domain Controller 1 (Windows Server 2019)
- vCenter Server Appliance
- VM's & vmdk's requiring write sync and performance
- OmniOS-2 / napp-it 'pro', pass-through: 2x NVMe, SATA-HBA, SATA-AHCI, share as NFS back to ESXi, SMB, minIO etc.

on OmniOS-2 NFS shares:
- Member Servers for other roles (Windows Server 2019)
- Servers: Veeam, media, etc (Windows 10 pro)
- Virtual desktops (Windows 10 pro)


Host 1 Option B :

on Local Optane 900P datastore 1:
- 40Gb Domain Controller 1 (Windows Server 2019)
- 20Gb vmdk SLOG-1 for OmniOS
- 180Gb vmdk mirror-1 for OmniOS

on Local Optane 900P datastore 2:
- 40Gb OmniOS / napp-it pro: 2x Optane vmdk, pass-through: 2x NVMe, SATA-HBA, SATA-AHCI, share as NFS back to ESXi, SMB, minIO etc.
- 20Gb vmdk SLOG-2 for OmniOS
- 180Gb vmdk mirror-2 for OmniOS

on Local SSD datastore:
- Powerchute UPS appliance (10Gb)
- vCenter Server Appliance (40-280Gb)

on OmniOS NFS shares:
- Member Servers for other roles (Windows Server 2019)
- Servers: Veeam, media, etc (Windows 10 pro)
- Virtual desktops (Windows 10 pro)

Host 1 Option C:

on Local SSD datastore:
- Powerchute UPS appliance
- Domain Controller 1 (Windows Server 2019)
- vCenter Server Appliance
- OmniOS / napp-it pro, pass-through: 2x Optanes, 2x NVMe, SATA-HBA, SATA-AHCI, share as NFS back to ESXi, SMB, minIO etc.

on OmniOS NFS shares:
- Member Servers for other roles (Windows Server 2019)
- Servers: Veeam, media, etc (Windows 10 pro)
- Virtual desktops (Windows 10 pro)
 
Last edited:

ARNiTECT

Member
Jan 14, 2020
92
7
8
I have joined both OmniOS servers to my AD and I can access the shares from domain and workgroup clients by name and IP.

I can not yet see the shares in the Windows 'Network' folder.

Napp-it setting:
netbios_enable=true

Network discovery is on

Windows features:
[ ] SMB 1.0/CIFS File Sharing Support (Automatic removal, Client, Server) all OFF
[✓] SMB Direct: ON

net view \\nappitserver
Shared resources at \\nappitserver
...shares listed
The command completed successfully

nbtstat -a nappitserver
nappitserver <00> UNIQUE Registered
nappitserver <20> UNIQUE Registered
Domain <00> GROUP Registered
MAC Address = xx-xx-xx-xx-xx-xx

*update:
With 'SMB 1.0/CIFS Client' enabled on DC1, I can see the shares in the Network folder. This service makes no difference to DC2 or any other clients, I tried adding SMB server and auto removal also. DC1 is the Master Browser (nbtstat -a DC1 > "**__MSBROWSE__*<01>")
Should SMB 1.0 need to be enabled? I thought OmniOS r151032+ was SMB 3.02?
 
Last edited:

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
Apple computers can announce themselves via Bonjour and network broadcasts. OmniOS or Solaris can announce themselves (AFP, SMB or TimeMachine shares) to Apple computers.

Microsoft decided not to do the same as this can produce a lot of network traffic. Only a single machine, the master browser searches and detects Windows machines on the local network. Other Windows computer can request a computer list from this master browser (The OmniOS or Solaris SMB server cannot act as a master browser). In your network the AD servers are the possible master browsers.

So the main question is what is needed for an AD server for the master browser role. I have not tested but it may be that for this SMB1 may be required. This is independent from the question which SMB version is used on a Windows/Solaris client (Solaris is 3.1, Illumos 3.02 with 3.1 coming) . I also have not tested if it makes a difference what min/max SMB version you set on OmniOS (Services > SMB > Properties)
 

ARNiTECT

Member
Jan 14, 2020
92
7
8
Thank you for the explanation.

I tried removing all SMB 1.0 features from the Primary DC1 (Master Browser) and after restart, the OmniOS SMB shares disappeared. The OmniOS shares then appeared in Secondary DC2 (has taken over as Master Browser), which still has SMB1.0 features installed.

I reinstalled 'SMB 1.0/CIFS Client' only (not server) on DC1 & DC2. DC1 is now Master Browser again.

The Master Browser server (either DC1 or DC2, not both) shows all of the drives on the network I would expect to see:
Domain: DC1, DC2, FileServer, 3x Client, OmniOS1, OmniOS2
Workgroup: 3x Clients

The other servers & clients show the following drives:
Domain: DC1, DC2, FileServer, 1x Client
Workgroup: 3x Clients

The 2x missing Domain Clients from 'other servers & clients' have service 'Function Discovery Resource Publication' turned OFF and they reappear when it is turned on. However, they are visible either way on the Master Browser. Could this be a clue to why OmniOS SMB shares are also only visible on the Master Browser?

The Workgroup machines, also seem to have their own Master Browser (my desktop PC), but this also can't see the OmniOS shares in Network folder.

'net view' only works on the Master Browser
'net view \\Name' works on all machines
'SMB 1.0/CIFS Client' is only installed on DC1 (Domain Master Browser) & DC2, 1x Domain client , 1x Workgroup client (Workgroup Master Browser).

Maybe I am just having problems with the connection between the Master Browser and others, I have posted the query in the Windows Forum.

I have not yet tested changing min/max SMB version either.
 
Last edited:

ARNiTECT

Member
Jan 14, 2020
92
7
8
I am having trouble getting the OmniOS/napp-it servers to connect to my domain on boot and stay connected.

As my posts above, I have 2x Windows Server 2019 Domain Controllers, which both start before OmniOS.
Host1: ESXi1>DC1>OmniOS1
Host2: ESXi2>DC2>OmniOS2

I joined the Napp-it servers by entering the domain details in the SMB>Active Directory menu and it confirmed that i had successfully joined the domain. I entered DC1 as the ad-domain-server into OmniOS1 and DC2 into OmniOS2, this way I hoped they would always be able to connect to the domain.

After OmniOS has booted, the console outputs the following:
WARNING: sata:sata_auto_online is set more than once in //etc/system. "set sata:sata_auto_online = 1" applied as the current setting.
WARNING: sd:sd_io__time is set more than once in //etc/system. "set sd:sd_io__time = 0xf" applied as the current setting.
SunOS... etc etc...
Date Time Server smbd[464]: smb_domain_getinfo: no DC info
Date Time Server last message repeated 3 times
then it repeats
...sometimes smbd[467], or [481], or [6857], or [10338]

Services > SMB
SMB/CIFS server: online
SMB/CIFS client: online

Services > SMB > Active Directory
header status shows:

Current state of SMB/CIFS Server: online
Current membership: domain [NETBIOS name] [*] [FQDN name]

I noticed some info is missing here

I could still access the SMB shared folders and files, but oddly in Windows 10, right click on a single folder, select properties takes 1-2 mins to display the properties box.

So I tried restarting the SMB server, but no change
I re-entered the domain details again and it says failed to connect (I think it said couldn't find domain controller)
I re-enter the details again and this time it says successful
DC2 header status, then shows:
Current state of SMB/CIFS Server: online
Current membership: domain [NETBIOS domain name] [*] [FQDN domain name] [+DC1.FQDN] [DC1 IP] [.] [Napp-it Server] [X-X-X-X-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX] [*] [NETBIOS name] [X-X-X-X-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX]

This is the length of info I remember it, but OmniOS2 is referring to the wrong domain controller DC1. I checked and OmniOS1 is refering to DC2.

The right-click folder properties box is now appearing instantly.

To test, I then restart a napp-it VM (keeping both domain controllers on) and I have to go through the same procedure again to ensure it is properly joined to the domain. But OmniOS2 is still refering to DC1.

krb5.conf is not edited by me, but OmniOS1 appears to be correctly referring to the IP of DC1 and OmniOS2 has IP of DC2.


OmniOS2 DNS settings (resolv.conf ):
search FQDN domain name
domain FQDN domain name
nameserver DC2 IP address

should the 'search' line be in there?

idmap list

add winuser:AdminUser@domainfqdn unixuser:root
add wingroup:AdminGroup@domainfqdn unixgroup:root

SMB properties are on defaults

I restart again and now OmniOS2 is refering to DC2.

I try restarting OmniOS1 but it is still refereing to DC2 as well, I try restarting again and re-entering the domain details, but I can't get it to refer to DC1.

Any suggestions as to what I should look into to making this more stable?
 
Last edited:

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
I would set both OmniOS to the primary domain controller of your domain and use the secondary only as a backup/failover system or a readonly controller. I am not sure if the secondary rw controller works correctly when the primary is offline.

btw
the double sata and timeout warning are uncritical and there when you start a default napp-it tuning with an older napp-it on newer OmniOS where sata hotplug mode and a shorter disk timeout are set by default. To remove the warning edit /etc/system or rerun System > Tuning and disable these two settings.
 

ARNiTECT

Member
Jan 14, 2020
92
7
8
So potentially, having a secondary domain controller is causing issues with connecting OmniOS to the active directory? My Primary/Secondary setup allows DC2 to take over when DC1 is down. Are you suggesting a failover cluster system? I understand Failover could be achieved using Windows Server features/roles, or through vCentre. Either way, setting up a failover cluster appears complicated and it looks like it wouldn't allow me to work on a DC independently of the other active DC.

For OmniOS1, the Napp-it active directory settings were set up with the primary IP of DC1 (no entry for secondary IP) and only DC1 is listed in the DNS nameservers (resolv.conf), but it is currently using DC2 (restarted OmniOS1 several times yesterday, will try again today. *Update, OmniOS1 is now staying on DC1 and OmniOS2 is staying on DC2) ...ideally there is a way to force OmniOS to use a specific DC.

I edited /etc/system and the double sata and timeout warnings have gone.
 
Last edited:

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
So potentially, having a secondary domain controller is causing issues with connecting OmniOS to the active directory?
I would expect only problems joining the secondary when the primary AD is offline. If you are already a member, using a different or readonly AD should be no problem ex with an AD per subnet and each OmniOS use its own AD.