nappit all in one, how to control SMB share permissions

[kumasan]

I have a nappit all on one setup with esxi/omnios and Im having some problems with permissions for my windows shares.
I have two ZFS file systems, a vmshare that is an NFS/SMB share and a general data partition.

Im using the system in home environment and dont care about setting up file permissions so I opted for simple settings during setup, guestok option I think it was . I have been able to access the SMB shares from windows and read/write to the fs with no problems until recently.

I have an NFS share that I use for my vm storage and it is also shared as SMB. Im trying to create a backup of the share files through file copy in windows but getting permission problems when I try to copy the "-flat" disk images. For these I get a warning:

"You require permission from Anonymous to make changes to this file"

This happens only for the disk image file, other files in same directory are ok. I thought I had enabled guest access for the entire partition so not sure why it is getting stuck. Also windows does not prompt me for login/password so no option to login as root.

I have to admit Im not up to speed with windows permissions and how to cross map permissions between zfs and the windows file system.

Ideally I would like to know how to set up a file system with:

o) Global shares accessable to everybody on windows with no password.
o) Private shares that requires password/login for some protected files and a way to authenticate on windows with the login/passwd.

Dont want to pay for pro version nappit with ACL support, just looking for how to setup some permissions without active directory. Im guessing that I could probably do the admin directly on solaris by editing some files/commands.

Appreciate any pointers as to how to get started.

Kuma

 

[_Gea]

Solarish/ napp-it use the SMB server from Sun with quite the same behaviour as Windows regarding NTFS alike ACL with permission inheritance and Windows SID in the filesystem. To set ACL, you can simply connect from Windows as user root for full permissions and set there whatever you want. Only restriction is that you should not set deny rules as they behave different on Solaris (order of rules is relevant) to Windows (respect first deny then allow) .

For a given share, you must decide between guest access (no user/password) or password restricted as you cannot mix (how should that work), so you need two shares
What you can do is using the same user/pw than on Windows (you must not enter user/pw then)

As the Solarish SMB server use ACL only, you should not set Unix permissions manually as this will delete all inheritance permissions (the most important Windows ACL feature) as this is unknown with simple Unix permissions

btw
If you want to mix NFS3 and SMB for the same filesystem you have the problem that NFS comes without authorisation and authentication so regarding permissions they are incompatible. This works only with a fully open ruleset where you can optionally use the firewall to restrict access.

 

[kumasan]

I think Im still a little confused.

For the public share I had selected guest access which seems to work except for the copy problem for the VHD file. Any ideas what might be going wrong here? Any way to force windows to ask me for credentials so I could access the share as root?

For the password protected share Im not sure how I should "connect as root" to make the changes. If I make the partition non guest than I would be prompted for credentials if I try to access the share. Then I could use windows properties panel to change things?:

"you can simply connect from Windows as user root for full permissions and set there whatever you want."

Also if I just want simple password at the share level can I skip using ACL and opt for simple password or is ACL the only way windows works?

Sorry for my lack of experience with windows permissions, most of my past work has been with unix.

P

 

[_Gea]

If you use guest access, you will never be asked for user/pw as this is intention of guest access
Even with guest, already set ACL must be respected so your behavior is a permission problem.
With guest, set shared foldee to everyony@=modify with inheritance to files and folders,
with NFS optionally set ZFS aclmode to restricted to hinder NFS to change ACL

If current ACL are a problem, reset them recursively to a wanted setting

You can use ACL on a share and not only on files. This can complicate settings and is mostly there for additinal global restrictions.
Avoid for first steps with Windows ACL

Windows permissions offer
- very detailled permissions (regarding open, create, edit, delete etc)
- many user and group permissions
- groups can contain groups, not possible on Unix -this is why Solarish come with extra SMB groups
- INHERITANCE of ACL for newly create files (current folder only, files, files and folders)

If you set ACL or Unix permissions, the other one goes to a setting that respects this,
but if you set Unix permissions, inheritance settings are deleted as they are not available on traditional Unix so avoid!

And
Solarish SMB is ACL only, just like real Windows.
I am glad about this as you can switch to Unix with an NTFS alike behaviour

 

[kumasan]

Hmm, trying to debug the copy problem for the .vmdk fule. In the nappit console it shows permission for the share as follows:
drwxrwxrwx+ 27 root root 30 Mar 28 20:39 (777)
ACL User/ Group acl acl-set details inheritance type option

0 user:root rwxpdDaARWcCos full_set rd(acl,att,xatt) wr(acl,att,xatt,own) add(fi,sdir) del(yes,child) x, s file,dir allow delete
1 everyone@ rwxpdDaARWc--s modify_set rd(acl,att,xatt) wr(att,xatt) add(fi,sdir) del(yes,child) x, s file,dir allow delete

If I click on properties/advances security settings from a windows 10 machine the problem file permissions shows it is owned by ANONYMOUS LOGON

For the non .vmdk files that can be copied they show permission:
Allow Everyone Special inheritedFrom:\\omnifs\vmshare

For the problem file the inherited from shows "None" and no permissions on it.

I suspect that vmware somehow is setting the permissions on the virtual disk files that results in a different ACL.

From google I found some articles that mention needing to add "ANONYMOUS LOGON" to the share permissions.

Any idea what might be going on?

The free napp-it will not let me manipulate the ACL via the GUI. Im wondering how to manage this from the raw omnios?

 

[_Gea]

You can modify ACL at console via /usr/bin/chmod but I would avoid as ACL are quite complex. Use Windows (or napp-it) for this

When NFS writes a file, it use its own permission rules, usually with nobody or the uid of the creator as reference, depending on OS.
The solution is to reset now all permissions recursively ex to a everyone@=modify, can be done via Windows or napp-it and the ACL extension (this is a free option). You can the set the zfs property aclmode of the NFS shared ZFS to restricted to avoid this in future.

Share permissions do not replace file permissions. They are an ADDITIONAL, global option for restrictions.