Gea - Help on a few things...


Active Member
Apr 12, 2016
I have been running a Napp-it all in one on esxi for a couple years now to replace an old ZFS server that I had running on macOS Sierra

for the most part its been a pretty good fit, however not without its issues....

I just had to destroy a 24TB media pool and rebuild because Napp-it / omnios-r151022-f9693432c2 i86pc refused to add new devices properly. At first I thought it had something to do with pass through but no... its a bug

I had a pool of 2 WD 8TB drives and it was fine with both showing ashif=12 and using full drive, I believe it was created outside of Napp it... but when I added another 8TB drive (basic vdev pool) with the Napp-it gui it added the drive with a ashift=9 and attached it at partition not drive level...

so .. reading the docs.. the designed behavior is that if a pool, even with 512 sector drives is created with ashift=12 any drives added will also be ashift=12 .. not the case

I created a couple test pools starting with ashift=12 devices and attaching a 512 drive napp-it attaches it as ashift=9 as verified by zdb
with this version of omnios and napp-it home-use free latest... you can't force ashift in the GUI so you are at the mercy of the programming

funny thing is that the 24TB pool, that all devs are 4k drives... when it was added incorrectly it may have been passed to omnios as a RDM through esxi rather than passing the controller which is what I am doing now.. but when rebuilding the pool and creating it with the same 3 drives, all though this time all 3 at the same time, zdb verified all 3 attached as whole disks with correct ashift...

additionally, sata hot-plugging not working at all in Napp-it. I have confirmed that the service is running and enabled in napp-it settings, and the sata controller is ICH10, being passed to the napp-it vm etc.. so it should work. nope.. had to use cfgadm and other solaris command line tools to clean up the dev tree and re configure the sata sockets as some were showing failed and unattached... and I didn't feel like rebooting napp-it and bring everything else down every time I needed to move drives around..

I have never gotten Napp-it's esxi snap integration to work ... I have followed the steps, set up the keys etc.. its simply either too confusing for someone with 2 masters to follow or just doesn't work in my current configuration with a free license

I have been backing this pool up to a backup shelf attached to the same server so not remote replication using the JOBS function and replication as that is the only snap-send-recv functionality that I see in Napp-it. and in the end.. it just was too painful to be helpful in my recent pool destroy / rebuild operation

because omnios and napp-it have issues with doing nested files systems and -R sends etc.. I just did it all manually.. creating manual snaps of each file system using -r and sending with -R but ensuring no child filesystem existed.. just to ensure I retained snap history so that once the pool was rebuilt, I could have it continue incremental snaps to the existing backup shelf... it worked but again. all manual as the GUI would have required me to set all these up as jobs and ensuring the right command options were sent it was just far more accurate and faster to do it manually

I am thinking highly of upgrading omnios to the latest long term stable but upgrading from omnios-r151022-f9693432c2 is really not supported.. it would requires 3 upgrades minimum and have to get by several roadblocks both with omnios and napp-it
so I installed omnios from .iso and Napp-it from wget to start from scratch... so I will loose all my settings, customizations, tunings, users etc...
I can get some things back if I scp manually some directories from the appliance_backup so I might try that but once again.. doing everything manually as napp-it free is essentially neutered
with the latest -38 LTS omnios and latest napp-it free.. several things have not been responding correctly.. I had to set up some vmxnet3 stuff like enabling MTU 9000 again in terminal using command lines.. GUI not working .. won't up/down. enable/disable or edit MTU correctly on vmxnet3 dev

so all in all... a very painful week thus far.. and further putting into relief for home lab, hobbyists, and students.. just how antiquated napp-it is starting to get
looking at Truenas very carefully as their free feature set is far more fleshed out than napp-it .. and lets face it... 1975 called and it wants its GUI back

gea.. please consider re factoring the GUI for the 'modern' age... working with Napp-it is like working with tape storage.. it might work but its not fast or elegant

also consider throwing free users some additional bones.. no ACL management, no encryption control, etc and omnios always seems to lag way behind with both operating system level services like SMB version as well as ZFS version... again TrueNAS SCALE when it hits release here shortly will be a lot more compelling.. based on Debian and with ZFS dev head being on linux will be a far more up to date experience and not so difficult to manage


Well-Known Member
Dec 31, 2010
1. 151022 is no longer suppoerted, update (151038 lts is current)
2. add ssh keys ti esxi (Omnios root), test remote execution of esxcli ex via remote console ssh command
3 do not create filesystems manually, use zfs send -r
4. i would do a clean install of 151038
napp-it is simple, the idea behind is a listing of properties with the option to modify when you click onto. Additionally, a new or modified menu should be done as easy as possible. napp-it is as I need it.If you do not like it, there are alternatives.