ZFS ACL confusion

[m4rm]

After a year of planning I finally moved all my data from mdraid to ZFS. I'm familiar with UNIX permissions but those mixed with ZFS ACLs cause me a headache.

My current situation:

I have a dataset (let's call it 'tank/data') that is shared via NFS and SMB. All data in the dataset are transfered from my old server over NFS. NFS work just fine, but I cannot delete any existing files via SMB. I can create new files and folders, though. I've tried setting aclinherit=on and giving everyone full_set allow rights.

My ultimate goal is to:

Have the dataset shared to users X and Y via SMB, and some other clients via NFS.

- X should have full permissions to dataset
- Y should have read and write permissions, but not delete (just the way it is working now)
- NFS full permissions


This is on OmniOS.


\\e

Some progress. Found out that by default OmniOS uses GNU ls and chmod which do not support ACLs. Had to modify $PATH a bit. Now I just need to figure out right ACL settings for user Y. Any tips are appreciated.

 

[_Gea]

SMB depends on ACL and user authentication.

With NFS3 there is no authentication. Permissions settings depend on
client OS (mostly Unix UID or user nobody) and client ip

If you share a filesystem over NFS and SMB: this is mostly incompatible
You can give full access for NFS with the share parameter root=ip
but I would share a filesystem with a everyone@ ACL (fully open).

and yes, you need /usr/bin/chmod and /usr/bin/ls for ACL settings
as every Solaris (derivate) use the GNU variants per default.

 

[m4rm]

SMB depends on ACL and user authentication.

With NFS3 there is no authentication. Permissions settings depend on
client OS (mostly Unix UID or user nobody) and client ip

If you share a filesystem over NFS and SMB: this is mostly incompatible
You can give full access for NFS with the share parameter root=ip
but I would share a filesystem with a everyone@ ACL (fully open).

and yes, you need /usr/bin/chmod and /usr/bin/ls for ACL settings
as every Solaris (derivate) use the GNU variants per default.

Yeah, I've been using root=@ip. I just want to know if it's possible to set ACL with read&write, but not delete permission to specific user. I tried to apply different permission sets to local user via napp-it, but it didn't seem to work.

Will ACLs override unix permissions? If I set /tank/dataset/test.txt permissions to root:root and 700, will I still be able to modify that file through SMB if there is a everybody@full_set allow ACL?

 

[_Gea]

Will ACLs override unix permissions?

Solaris NFS4 ACL are modern fine granular Unix permissions that are quite similar to Windows NTFS ACLs (beside deny behavior) and they interact with "traditional" Unix permissions.

If you modify/set ACL, the traditional permissiones are changed to a according value.
If you modify/set traditional Unix permissions (like 700), ACL settings are changed as well + all ACL inheritance settings are deleted as there is no similar behaviour in traditional Unix permissions.

So if you need SMB (ACL only) do never set traditional settings or you are lost with SMB. Restrict all permissions (for all services, SMB, NFS, AFP, FTP etc) via ACL only.
Optionally set aclmode to restricted to hinder NFS to do a chmod with traditional permissions.

 

[m4rm]

Solaris NFS4 ACL are modern fine granular Unix permissions that are quite similar to Windows NTFS ACLs (beside deny behavior) and they interact with "traditional" Unix permissions.

If you modify/set ACL, the traditional permissiones are changed to a according value.
If you modify/set traditional Unix permissions (like 700), ACL settings are changed as well + all ACL inheritance settings are deleted as there is no similar behaviour in traditional Unix permissions.

So if you need SMB (ACL only) do never set traditional settings or you are lost with SMB. Restrict all permissions (for all services, SMB, NFS, AFP, FTP etc) via ACL only.
Optionally set aclmode to restricted to hinder NFS to do a chmod with traditional permissions.

Ok cool.

Why ACLs do not work when I try to apply them via napp-it? Applying with chmod directly from cli does work.

 

[_Gea]

Ok cool.

Why ACLs do not work when I try to apply them via napp-it? Applying with chmod directly from cli does work.

What have you done and what is not working?

 

[m4rm]

What have you done and what is not working?

I create a new ACL in napp-it then run 'ls -v' on CLI but it's not there. Does it only get applied to files created after applying the ACL?

 

[_Gea]

I create a new ACL in napp-it then run 'ls -v' on CLI but it's not there. Does it only get applied to files created after applying the ACL?

From history Solaris and its derivates prefer GNU versions of ls and chmod with the default path. The Solaris version that supports ACL is /usr/bin/ls and /user/bin/chmod

 

[bmh.01]

NFS wise, i've had great sucess (with nexentastor 3/4) using anon=*uid* and just assigning that user the required permissions from a windows cifs client. No idea if that will help but should let you set perms for the nfs users as long as they can all be the same access level wise. (in my case shared folder with isos for esxi to mount)

 

[_Gea]

As there is no authentication with NFS3 and the only verification is the client ip that can be faked easily, there is no real advantage against a "allow everyone" setting.
NFS3 is only perfect if you need a very fast shared file-service in a secure network.

 

[m4rm]

From history Solaris and its derivates prefer GNU versions of ls and chmod with the default path. The Solaris version that supports ACL is /usr/bin/ls and /user/bin/chmod

Yes, I've fixed the path earlier, I can see the ACLs correctly but new ACLs applied through napp-it will not show.

 

[_Gea]

Yes, I've fixed the path earlier, I can see the ACLs correctly but new ACLs applied through napp-it will not show.

If the ACL is not shown, it is not applied (napp-it itself does nothing else than calling chmod). Only problem can be filenames with special characters that are different in web and locally.

Can you please send me (community@napp-it.org) the following:
OS release
napp-it release
name of the pool and filesystem

and if you tried to modify a folder or a file ACL (name of folder or file)
so I can check for a general problem

 

[m4rm]

If the ACL is not shown, it is not applied (napp-it itself does nothing else than calling chmod). Only problem can be filenames with special characters that are different in web and locally.

Can you please send me (community@napp-it.org) the following:
OS release
napp-it release
name of the pool and filesystem

and if you tried to modify a folder or a file ACL (name of folder or file)
so I can check for a general problem

Sure, I'll do that.

 

[_Gea]

I can confirm that the ACL settings done via chmod on OmniOS are not reflected on Windows (even a SMB restart does not help)

This needs some further investigations.
Workaround: set ACL on Windows in the meantime

Update:
Please check aclmode settings
It must be set to passthrough at pool and filesystem level or it hinders chmod to modify permissions

set via
zfs set aclmode=passthrough pool or
zfs set aclmode=passthrough pool/filesystem

 

[m4rm]

I can confirm that the ACL settings done via chmod on OmniOS are not reflected on Windows (even a SMB restart does not help)

This needs some further investigations.
Workaround: set ACL on Windows in the meantime

Update:
Please check aclmode settings
It must be set to passthrough at pool and filesystem level or it hinders chmod to modify permissions

set via
zfs set aclmode=passthrough pool or
zfs set aclmode=passthrough pool/filesystem

Sorry, I have not had time to tinker around with my system and mail you about the napp-it problem, I will do it later today or tomorrow.