ZFS Issue finding Napp-It users when setting NTFS permissions

g0dM@n

Supreme [H]ardness
Joined
Nov 18, 2005
Messages
5,483
I've set up several users through napp-it already. They work. I can map my SMB shares successfully without issue, but here is my problem.

If I map as root (or another administrator account that I use), and I go to NTFS security, it doesn't find the user, EVEN THOUGH IT EXISTS in Napp-It!


Even if I do a search the standard way, it doesn't see the accounts:


I tried several things last week, such as turning off the Windows firewall, real-time virus scanning, dismantling a homegroup set up on one of my desktops (by accident) on my network, etc. I finally got it working by trying all of the above, but it's broken again. Now, mind you, the search for napp-it users only worked from VMs on the same ESXi host, not from any physical desktops.

Anyone have any idea? This is driving me nuts, especially b/c it's intermittent. I didn't change anything after I had it working last week. When it was working, in the second screenshot you see, it would show all of the napp-it users and in the "In Folder" column it would show the hostname of the napp-it VM.
 
Have you set id-mappings?

As you are in Windows Workgroup mode, do not use any mappings.
This is a way to map a nonlocal Windows AD user to a local Unix user like
AD-Domain\anyone=Unix:root

So if you want to use the share with full permissions, use it as regular user root
and delete all mappings.
 
I didn't set id-mapping, if you're referring to linking a Windows user account to a unix user. I just created the same Unix username as the Windows username. There is no domain on my network, so it's all workgroup mode.

What's funny is last week I was able to see the napp-it users in the Find Now utility! Now, I don't see the users.

I want to have the option of adding/removing users even when my evaluation period is over. I have a main VM I map a drive letter my main SMB share via root, and then want to go and edit NTFS permissions that way. I rebuilt my setup, so it's as such:
ZFS hostname: omni-napp with static IP
SMB Share: \\omni-napp\shares
I then created several folders underneath, for example:
\\omni-napp\shares\media
\\omni-napp\shares\TV
\\omni-napp\shares\Garo (me)
\\omni-napp\shares\Jocelyn (my wife)

I map drive letter N: as root from my Windows VM, go down to those folders, and want to have the option of adding users to the NTFS perms. Those users are already created in napp-it, and match up with Windows accounts (workgroup mode of course). I swear it was working last week. I'm not sure why it no longer works.

See my mappings are default:


Thanks for dropping in, by the way, Gea! Happy new year!
 
I created a Windows account "root" and assigned it the same password as for OmniOS. I'm now seeing the users I mentioned. This is EXACTLY what I want, so that I have full control over adding, removing users, even after the eval period. In RED are the accounts I created in napp-it. In blue are the built-in accounts. I blocked out the accounts I didn't mention, for security purposes:
 
mmhh.
Is this a Windows Home or Pro

There no real reason why you should need a Windows user account root.
Login to the share as Unix user root should be enough.
 
Win7 Pro x64.

Yeah, it's weird, and it's been intermittent with being able to see the "omni-napp" (my hostname for napp-it ZFS) accounts.
 
The problem is back. This is horrible. I cannot edit any NTFS permissions.

I've tried mapping my main share that holds all other directories, and then try setting perms on subdirectories, but it never finds any of my linux user accounts. I've also tried disconnecting all drive mappings on my Windows 7 Pro PC, and then going directly to the share via UNC and I still cannot set any ntfs perms. It asks me for credentials and I put in root credentials, but it just doesn't see any accounts listed.
 
The problem is back. This is horrible. I cannot edit any NTFS permissions.

- not even as user root?
- even when you reset ACL to default or tried on a new filesystem with ACL defaults?
 
- not even as user root?
- even when you reset ACL to default or tried on a new filesystem with ACL defaults?

Yes, even as user root. When I go to edit the ntfs perms, it asks for a login, and I type in the root login. I spun up a WHS 2011 server and from there it worked. It's just so weird how it's intermittent.

You think I should try to create a new filesystem and test? I didn't try resetting ACLs to defaults. I don't want to because I have tons of data in there already.
 
As I am not aware of a OmniOS bug regarding your problems,
the problem is mainly due Windows/NFS4 ACL permissions or some (mostly home)
Windows editions not allowing to set ACL remotely.

If you create and share a new filesystem with default ACL you can decide between the two options.
If your WHS 2011 work, you can set ACL from there.
 
As I am not aware of a OmniOS bug regarding your problems,
the problem is mainly due Windows/NFS4 ACL permissions or some (mostly home)
Windows editions not allowing to set ACL remotely.

If you create and share a new filesystem with default ACL you can decide between the two options.
If your WHS 2011 work, you can set ACL from there.

I hope it sticks with WHS 2011 working b/c the free version of napp-it won't allow me to set ACL and I can't afford to shell out $300. I do wish it was more affordable for home users. It's an awesome product!
 
Your other option is
- /usr/bin/chmod (CLI command to set ACL)

but with the right Windows versions using Windows is easiest.

btw
The ACL extension alone is 25 Euro per year.
If you need once, you can request a 2 day evalkey online
 
Your other option is
- /usr/bin/chmod (CLI command to set ACL)

but with the right Windows versions using Windows is easiest.

btw
The ACL extension alone is 25 Euro per year.
If you need once, you can request a 2 day evalkey online

Thanks buddy.
Yeah, I need to learn the CLI, but I couldn't find any tutorials for dummies.
 
What do ya know?
This problem is back as I was adding a directory to make adjustments to some backups and my issue came up as "unable to lookup usernames for display" when trying to set NTFS permissions from Windows.

I finally used CLI to set the permissions, but this is definitely annoying to say the least. Wish it worked in Windows. Still don't know why.

This command worked like a charm:
root@xxxx:/usr/bin# chmod A=user:USERNAME:modify_set:allow "/SHARENAME/Shares/Backups/MACHINE-NAME/W10"
 
As it worked for years and suddenly no longer, I would suppose that propably a Windows update introduced the problem (increasing default security demands) ex forcing SMB 2/3 or secured network as a default. If this is the case either reduce Windows security settings or update OmniOS to support SMB 3 and many other new features like encryption, trim, special vdev, faster resilvering etc.

see https://github.com/omniosorg/omnios-build/blob/r151032/doc/ReleaseNotes.md
 
Last edited:
Wow, good to see you again, Gea!
I have had bad luck upgrading OmniOS and/or Napp-It. When I had it crap out on my earlier this year (yes, unfortunately it did), I rebuilt a brand new VM from the AIO Napp-It solution and migrated the disks to it, recreated my users with the same mappings and everything worked like a charm. If I do upgrade, I may try upgrading OmniOS, but if I struggle I'll just rebuild. I'm actually waiting for the holiday deals (BF, cyber monday, etc.) to pick up 10TB drives. My 3TB 6 drive RaidZ2 is jam packed and wants to retire! Hoping to go with 3-4 10TB in Z1. I think Z2 has been overkill and a waste of disk for what I do, and I run robocopy jobs to back up the important stuff anyway.
 
Back
Top