FreeNAS 11.3-BETA1 - Now available!

[Stilez]

I don't believe there are any changes WRT the recycle bin, but once again if you've observed an issue, feel free to PM me and we'll work to get it resolved.

I'm thinking more, a good explanation of what the settings and modules do, and their params. The user guide defers a bit too much to Samba docs for that, especially for the modules that need options adding, but the Samba docs are over-terse and don't explain either. Equally some of the options that are individually handled in the UI havent histoprically been as well explained as they might.

With all the changes described, it's worth just reviewing the Samba side of *Nas docs, to confirm that the new changes, any settings, and their implications, will be clear to users at release.

Incidentally, how stable is 11.3 Beta right now, given all this wonderful QA and dev work? If I find nothing especially relevant to me in outstanding issues on Jira, should I consider it safe to early-upgrade to?

 

[appliance]

glitches:
- \Accounts\User: user hint "Enable password login"="Enable password logins and authentication to SMB shares. " i thought it's for ssh not smb, what is this setting, downgrading a specific user to a smb guest or just or just disable samba for the user? i used it to disable nonsudo root and it works
- \Accounts\User: hint "Lock User"="Set to disable logging in to this user account." confusing, this is a lock not "shell"="nologin" choice, and help refers to "Setting this option grays out Disable password login, which is mutually exclusive. " which again doesn't sound like samba
- Services\SSH: hint "Allow password authentification" links to non-existing "http://the.earth.li/{6}Esgtatham/putty/0.55/htmldoc/Chapter8.html"
- sshd_config: "NoneEnabled=yes" being added and can't find why it is needed, middleware also overwrites the "PermitRootLogin=no" choice
- sshd: again some permissions "_secure_path: cannot stat /home/user/.login_conf: Permission denied"
- Storage\Pools: hint "Permissions" link goes to "https://ixsystems.com/documentation/freenas/11.3-BETA1/storage.html/#ace-permissions" -> "The requested page does not exist "
now this is related to dataset permissions, but it sucks to be visually being ensured the permissions are there in these dialogs:
- \Accounts\User: user home permissions (checkboxes) not used, found u+rwx g+rwx set (also in 11.2)
- \Accounts\User: home and .ssh folders set with wrong permissions, ssh via key impossible (also in 11.2)
- CLI: setfacl "setfacl: user: branding mismatch; existing ACL is NFSv4, entry to be removed is POSIX.1e" -> would like to find the new ACL editor:) "HOME" profile is bad while setfacl of NFS style is just unbearable .. couldn't set it up the poor ssh access within 2 hours other than slapping HOME permissions...

 

[zvans18]

It seems like 11.3 has a stronger emphasis on enforcing best practices ("hand holding," but I don't really like to refer to things like that). For instance, my pool is 3 mirrors of 2x4TB Reds. I had a single 6TB Red that passed burn in testing I wanted to add and then mirror later manually/whenever GUI support for that is added. Not allowed. I couldn't add anything except another mirror. So I decided to put in an old 500GB until the second 6TB came in, but the GUI won't allow that either; they had to be the same size. This actually could be a real problem if they didn't allow some slop for non identically sized drives. I know why all of that is a bad idea, but I like to experiment, and there isn't some sort of check that says "I know this is a terrible idea, but please let me do it anyway" so my only option would be to roll back. I submitted a ticket specifically about not allowing a mirror of differently sized disks (NAS-103993)

note: I acknowledge I could be missing something obvious, and if so, maybe that speaks to the UI needing some tweaking?

UPDATE: was told this was a duplicate of NAS-102998, but that doesn't seem to exist?

 

[anodos]

- CLI: setfacl "setfacl: user: branding mismatch; existing ACL is NFSv4, entry to be removed is POSIX.1e"

The setfacl command in FreeBSD is written such that it can modify POSIX.1e ACLs for filesystems that use that type of ACL, and NFSv4 ACLs for filesystems that use NFSv4 ACLs. You have to use the correct syntax.

-> would like to find the new ACL editor:) "HOME" profile is bad while setfacl of NFS style is just unbearable .. couldn't set it up the poor ssh access within 2 hours other than slapping HOME permissions...

Create dataset on zpool to host user home directory. Create "generic" (not SMB dataset). Specify a path relative in that dataset to use as your user's home directory.

The "HOME" template under the ACL manager is to set ACLs specifically for SMB [homes] shares. The "homes" shares in FreeNAS dynamically create a private share for every NAS user. This is extremely powerful. In an AD environment with 1000 users, it will create and auto-permission their own private place to store data with zero admin interaction once it's configured correctly. The HOMES ACL template gives a default ACL that for a path specified as a "homes" share that will ensure that only the user (and the group specified as the SMB admin) have read access to the user's private share (both over SMB and SSH). I think I will probably rename the HOMES template to SMB_HOMES to maybe reduce confusion. The goal of the templates is to avoid throwing users into the deep-end of NFSv4 ACLs by providing some common permissions sets. I'm happy to make changes to make things clearer.

 

[xlf]

Thanks for the discussions. Meanwhile, the world keeps on turning. This morning i read about a new ransomware "nextcry" attacking unpatched nextcloud instances, properly encrypting the contents and applying their fucked up business model on some systems.

Is it just me? I can't get over what i read here: iX stating that they will decide to keep holding on legacy freebsd and ports, and seemingly most people crying about the design choices in the new ui.

Jailer wrote: "FreeNAS is a storage appliance designed to be used on a private and secured network. Jails are just an extra to add some nice additional functionality to the system" . Jails are at the core of plugins, and then from what i see owncloud/nextcloud might be one of the things you might want to "have" as a "prosumer" and even for some SME offices. Additionally, your security assumptions are going to break your neck if you focus all your efforts on fencing the perimeter, putting some security gate inbetween the world out there and your little garden. Miscreants nowadays break in, establish stronghold, move laterally. They have time and come friday afternoon, they are going to royally f*** you. I've seen companies shutting down production for weeks. Pcs, Servers, Machines (Machine Controls) all deemed unsafe and set up / bought anew.

In that light, me, i'm just concerned. Me and my "customers" haven't paid for the software, we're thankful for it and we'd like to express our deep concern at this stage. Finally, i'd really hope to be able to stay with freeNAS with all the systems i support, (1 home system, 1 uni department filer, 1 SME file server), but moving on to plain FreeBSD or something entirely different is getting closer.

Re: Telemetry: https://www.zdnet.com/article/windo...t-faces-new-probe-over-how-it-uses-your-data/ , Microsoft have just been slapped from the german federa data protection officers for the exact reason their telemetry being encrypted and intransparent. https://www.heise.de/newsticker/mel...-fuer-den-Einsatz-von-Windows-10-4584678.html

If the data you phone home is of no concern, there should be no reason to encrypt it. At least, show the cleartext of the messagesto the admins (in the UI), and just use TLS for the transport. And best, make it opt-in.

So, at least, you have opt-out. Please don't do the ubiquity on us. Unfortunately, it's still an uphill fight for F/OSS against the big ones, and you are playing with fire. While still nobody gets fired for buying ...., scrutiny on F/OSS and derived products is much much more burdensome if you want to make a case and advocate for it in any organization. Hopefully, that's some food for thought for the marketing folks.

As i said, the world keeps on turning, choices need to be made.

 

[danb35]

This morning i read about a new ransomware "nextcry" attacking unpatched nextcloud instances

...and what you've read is almost certainly incomplete; the vulnerability appears to not be in Nextcloud as such, but in nginx/php-fpm:

Nextcry? Encrypted all files through my instance

Just a warning. It seems there’s a vuln somewhere as my instance of NextCloud got taken over today. My server was locked down already, using SSH keys and NextCloud was up to date. Something has gone through and encrypted everything and asking for crypto to unlock. Luckily I have everything...

help.nextcloud.com

Oops, the FreeNAS plugin runs under nginx. Well, maybe this will be good enough reason not to use the half-baked plugin for Nextcloud.

iX stating that they will decide to keep holding on legacy freebsd and ports,

Sadly, it's been a problem for at least the last five years--iX can't get a new FreeNAS release out before the FreeBSD release underlying the current release goes EOL. As a result, some software in jails won't install or update without workarounds. I don't know that the security implications of this are well-established at this point, but it's safe to say they're non-negligible.

 

[Patrick M. Hausen]

One question: can I install the BETA on an 11.3-nightly system? Like 11.3-MASTER-201910141131, which we are currently running?
Looks like I need to manually download and use an update file, switching trains is forbidden and freenas-update -T FreeNAS-11.3-BETA update just installs a more recent nightly build ...

Thanks!
Patrick

 

[Patrick M. Hausen]

One question: can I install the BETA on an 11.3-nightly system? Like 11.3-MASTER-201910141131, which we are currently running?

Answering myself: manual update seems to work.

Afterwards do midclt call update.set_train FreeNAS-11.3-BETA in a root shell.

Kind regards,
Patrick

 

[appliance]

Create dataset on zpool to host user home directory. Create "generic" (not SMB dataset). Specify a path relative in that dataset to use as your user's home directory.

i did this earlier when i realized this (system) dataset is not even going to be shared via samba. solved everything. thanks for ACL efforts.

 

[anodos]

i did this earlier when i realized this (system) dataset is not even going to be shared via samba. solved everything. thanks for ACL efforts.

I will do some investigation of this later. If you set a dataset to be an SMB dataset and then specify a user home directory to be located inside this dataset, then middleware will issue a `filesystem.setperm` job with the option `stripacl` on the user's home directory. In theory this should fix the problem with .ssh permissions. If this is failing then we need to fix it.

 

[appliance]

in 11.3, system dataset change didn't complete (if 20min isn't enough on a new build with 0 VMs/jails than my bad), so i end up without jails
jails UI: You have 2 poolsmarked active for iocage usage
iocage CLI: ImportError: Failed to initialize: [Errno 2] No such file or directory (something like this)

 

[anodos]

i did this earlier when i realized this (system) dataset is not even going to be shared via samba. solved everything. thanks for ACL efforts.

I tracked down the issue and fixed it. In BETA2 you will be able to create an SMB dataset, set permissions on it, then create users and specify that their home directories be located on the SMB dataset. When you upload an SSH key the .ssh directory will be created with the correct permissions.

More details:
SMB datasets have a restricted aclmode. This prevents chmod() from altering the POSIX mode if an extended ACL is present. When a user home directory is targeted at an SMB dataset, the middleware will make the user home directory inside the dataset, strip the ACL from it, and apply the mode specified in the the account form.

Caveat:
The ACL manager is not aware of your home directory settings. It is optimized for speed (because we sometimes have to do this on millions of files). If you select "recursive" it will change the ACL on everything in the dataset. If you select "recursive" and "traverse", it will change the ACL on the dataset and all child datasets. This means that you will need to use the account UI to fix the permissions on user home directories after ACL changes (so it's better to set the ACL correctly from the get-go).

 

[appliance]

11.3 bugs in replication:
- when editing a replication task, there's "Run automatically", "Snapshot Replication Schedule" checkboxes. After altering "Run automatically" checkbox, another item "Schedule" appears suddenly, and that looks like a duplicate of the second checkbox.
- multiple datasets replication is not possible due to "cannot open 'target/Replication/replicateddataset': dataset does not exist cannot receive new filesystem stream: dataset does not exist." error. Obviously that dataset should be created automatically. The only chance is to make sure source datasets are from the same pool.
- reporting charts have last data point at 0, chart looks bit weird at the end
- ups setup is bit more complex than neccessary, i though of all of the settings can be detected automatically (port ehm.. this note doesn't help). Would love power consumption in reporting!
all fixed, but each task is with big delays

 

[macatarere]

Three successful 11.3-BETA1 installs to X8SIE with BAR Plus 3.1 32/64/128GB but not for long, they all stalled at the Booting... message. Installed to a mirror of WD 2.5" HD's, connected to sata ports, they soon failed to boot too. 11.2-U7 is booting reliably on the same board with a mirror of Cruzer Blade 2.0.

The sata and usb ports connect to the same Ibex Peak 3420 chipset, I'm guessing this is an 11.3 3420 chipset issue?

 

[Rand]

Just wanted to throw this out there, before and after update - (# of striped disks) - looks like an improvement;)

 

[appliance]

I tracked down the issue and fixed it. In BETA2 you will be able to create an SMB dataset, set permissions on it, then create users and specify that their home directories be located on the SMB dataset. When you upload an SSH key the .ssh directory will be created with the correct permissions.

i've created one dataset as a SMB home share and subdirectories per user and it works in beta1. The user folder names just need to be lowercase, oddly (it's documented, and this is the only Samba moment where case matters). Then i deleted those folders and created subdataset per user (to let them see .zfs folder). Also works. I like this. But ACL editor won't change the permission of existing files/directories in any mode (passthrough/restricted, inherit, apply recursively). Or at least from what i see in midnight commander..permissions stay under the creator. (reviewing tons of folders via getfacl is impossible, i need a file manager for sure). The problem is i need to set up files for all users manually (create basic folders, restore backed up files), then i want to limit the access to actual users. I had a high hope ACL editor, working at least at the dataset level, could do this using recursivity.

 

[blueether]

So I decided to put in an old 500GB until the second 6TB came in, but the GUI won't allow that either; they had to be the same size.

it can be done with stripes in the nightly build, just add the first disk then extend it, not the eaisist way to do it but will work

 

[blueether]

another issue, changing the system data set it doesn't seem to finish in the GUI. but if you refresh the GUI it looks to have been set

 

[zvans18]

it can be done with stripes in the nightly build, just add the first disk then extend it, not the eaisist way to do it but will work

I ended up using inspect element to remove the "disabled = true" on the extend button. Later, since my pool is backed up and also not that critical, I detached the 500GB to give me full vdev capacity and then rebalanced the data across the pool. I'll mirror it when I get another disk

 

[anodos]

i've created one dataset as a SMB home share and subdirectories per user and it works in beta1. The user folder names just need to be lowercase, oddly (it's documented, and this is the only Samba moment where case matters).

Samba cleans up and normalizes the account name, and this normalized name is what's used to fill in the %u macro in the smb.conf. tl;dr the behavior will never change, and it's better to just keep your account names lower-case.

Then i deleted those folders and created subdataset per user (to let them see .zfs folder). Also works. I like this. But ACL editor won't change the permission of existing files/directories in any mode (passthrough/restricted, inherit, apply recursively).

Code:

root@adtest[~]# python3                      
Python 3.7.5 (default, Nov 15 2019, 13:07:21) 
[Clang 8.0.0 (tags/RELEASE_800/final 356365)] on freebsd11
Type "help", "copyright", "credits" or "license" for more information.
>>> from middlewared.client import Client
>>> Client().call('filesystem.getacl', '/mnt/dozer/SMB')
{'uid': 65534, 'gid': 65534, 'acl': [{'tag': 'owner@', 'id': None, 'type': 'ALLOW', 'perms': {'READ_DATA': True, 'WRITE_DATA': True, 'APPEND_DATA': True, 'READ_NAMED_ATTRS': True, 'WRITE_NAMED_ATTRS': True, 'EXECUTE': True, 'DELETE_CHILD': False, 'READ_ATTRIBUTES': True, 'WRITE_ATTRIBUTES': True, 'DELETE': False, 'READ_ACL': True, 'WRITE_ACL': True, 'WRITE_OWNER': True, 'SYNCHRONIZE': True}, 'flags': {'BASIC': 'NOINHERIT'}}, {'tag': 'group@', 'id': None, 'type': 'ALLOW', 'perms': {'READ_DATA': True, 'WRITE_DATA': True, 'APPEND_DATA': True, 'READ_NAMED_ATTRS': True, 'WRITE_NAMED_ATTRS': False, 'EXECUTE': True, 'DELETE_CHILD': False, 'READ_ATTRIBUTES': True, 'WRITE_ATTRIBUTES': False, 'DELETE': False, 'READ_ACL': True, 'WRITE_ACL': False, 'WRITE_OWNER': False, 'SYNCHRONIZE': True}, 'flags': {'BASIC': 'NOINHERIT'}}, {'tag': 'everyone@', 'id': None, 'type': 'ALLOW', 'perms': {'READ_DATA': True, 'WRITE_DATA': False, 'APPEND_DATA': False, 'READ_NAMED_ATTRS': True, 'WRITE_NAMED_ATTRS': False, 'EXECUTE': False, 'DELETE_CHILD': False, 'READ_ATTRIBUTES': True, 'WRITE_ATTRIBUTES': False, 'DELETE': False, 'READ_ACL': True, 'WRITE_ACL': False, 'WRITE_OWNER': False, 'SYNCHRONIZE': True}, 'flags': {'BASIC': 'NOINHERIT'}}]}
>>> new_acl = Client().call('filesystem.get_default_acl', 'RESTRICTED')
>>> print(new_acl)
[{'tag': 'owner@', 'id': None, 'perms': {'BASIC': 'FULL_CONTROL'}, 'flags': {'BASIC': 'INHERIT'}, 'type': 'ALLOW'}, {'tag': 'group@', 'id': None, 'perms': {'BASIC': 'MODIFY'}, 'flags': {'BASIC': 'INHERIT'}, 'type': 'ALLOW'}]
>>> Client().call('filesystem.setacl', {'path': '/mnt/dozer/SMB', 'dacl': new_acl, 'options': {}})
41
>>> Client().call('filesystem.getacl', '/mnt/dozer/SMB')
{'uid': 65534, 'gid': 65534, 'acl': [{'tag': 'owner@', 'id': None, 'type': 'ALLOW', 'perms': {'BASIC': 'FULL_CONTROL'}, 'flags': {'BASIC': 'INHERIT'}}, {'tag': 'group@', 'id': None, 'type': 'ALLOW', 'perms': {'BASIC': 'MODIFY'}, 'flags': {'BASIC': 'INHERIT'}}]}
>>> Client().call('filesystem.getacl', '/mnt/dozer/SMB/testfile')
{'uid': 0, 'gid': 65534, 'acl': [{'tag': 'owner@', 'id': None, 'type': 'ALLOW', 'perms': {'READ_DATA': True, 'WRITE_DATA': True, 'APPEND_DATA': True, 'READ_NAMED_ATTRS': True, 'WRITE_NAMED_ATTRS': True, 'EXECUTE': False, 'DELETE_CHILD': False, 'READ_ATTRIBUTES': True, 'WRITE_ATTRIBUTES': True, 'DELETE': False, 'READ_ACL': True, 'WRITE_ACL': True, 'WRITE_OWNER': True, 'SYNCHRONIZE': True}, 'flags': {'BASIC': 'NOINHERIT'}}, {'tag': 'group@', 'id': None, 'type': 'ALLOW', 'perms': {'READ_DATA': True, 'WRITE_DATA': False, 'APPEND_DATA': False, 'READ_NAMED_ATTRS': True, 'WRITE_NAMED_ATTRS': False, 'EXECUTE': False, 'DELETE_CHILD': False, 'READ_ATTRIBUTES': True, 'WRITE_ATTRIBUTES': False, 'DELETE': False, 'READ_ACL': True, 'WRITE_ACL': False, 'WRITE_OWNER': False, 'SYNCHRONIZE': True}, 'flags': {'BASIC': 'NOINHERIT'}}, {'tag': 'everyone@', 'id': None, 'type': 'ALLOW', 'perms': {'READ_DATA': True, 'WRITE_DATA': False, 'APPEND_DATA': False, 'READ_NAMED_ATTRS': True, 'WRITE_NAMED_ATTRS': False, 'EXECUTE': False, 'DELETE_CHILD': False, 'READ_ATTRIBUTES': True, 'WRITE_ATTRIBUTES': False, 'DELETE': False, 'READ_ACL': True, 'WRITE_ACL': False, 'WRITE_OWNER': False, 'SYNCHRONIZE': True}, 'flags': {'BASIC': 'NOINHERIT'}}]}
>>> Client().call('filesystem.getacl', '/mnt/dozer/SMB/testdir')
{'uid': 0, 'gid': 65534, 'acl': [{'tag': 'owner@', 'id': None, 'type': 'ALLOW', 'perms': {'READ_DATA': True, 'WRITE_DATA': True, 'APPEND_DATA': True, 'READ_NAMED_ATTRS': True, 'WRITE_NAMED_ATTRS': True, 'EXECUTE': True, 'DELETE_CHILD': False, 'READ_ATTRIBUTES': True, 'WRITE_ATTRIBUTES': True, 'DELETE': False, 'READ_ACL': True, 'WRITE_ACL': True, 'WRITE_OWNER': True, 'SYNCHRONIZE': True}, 'flags': {'BASIC': 'NOINHERIT'}}, {'tag': 'group@', 'id': None, 'type': 'ALLOW', 'perms': {'READ_DATA': True, 'WRITE_DATA': False, 'APPEND_DATA': False, 'READ_NAMED_ATTRS': True, 'WRITE_NAMED_ATTRS': False, 'EXECUTE': True, 'DELETE_CHILD': False, 'READ_ATTRIBUTES': True, 'WRITE_ATTRIBUTES': False, 'DELETE': False, 'READ_ACL': True, 'WRITE_ACL': False, 'WRITE_OWNER': False, 'SYNCHRONIZE': True}, 'flags': {'BASIC': 'NOINHERIT'}}, {'tag': 'everyone@', 'id': None, 'type': 'ALLOW', 'perms': {'READ_DATA': True, 'WRITE_DATA': False, 'APPEND_DATA': False, 'READ_NAMED_ATTRS': True, 'WRITE_NAMED_ATTRS': False, 'EXECUTE': True, 'DELETE_CHILD': False, 'READ_ATTRIBUTES': True, 'WRITE_ATTRIBUTES': False, 'DELETE': False, 'READ_ACL': True, 'WRITE_ACL': False, 'WRITE_OWNER': False, 'SYNCHRONIZE': True}, 'flags': {'BASIC': 'NOINHERIT'}}]}
>>> Client().call('filesystem.setacl', {'path': '/mnt/dozer/SMB', 'dacl': new_acl, 'options': {'recursive': True}})
44
>>> Client().call('filesystem.getacl', '/mnt/dozer/SMB/testfile')
{'uid': 0, 'gid': 65534, 'acl': [{'tag': 'owner@', 'id': None, 'type': 'ALLOW', 'perms': {'BASIC': 'FULL_CONTROL'}, 'flags': {'BASIC': 'NOINHERIT'}}, {'tag': 'group@', 'id': None, 'type': 'ALLOW', 'perms': {'BASIC': 'MODIFY'}, 'flags': {'BASIC': 'NOINHERIT'}}]}
>>> Client().call('filesystem.getacl', '/mnt/dozer/SMB/testdir')
{'uid': 0, 'gid': 65534, 'acl': [{'tag': 'owner@', 'id': None, 'type': 'ALLOW', 'perms': {'BASIC': 'FULL_CONTROL'}, 'flags': {'BASIC': 'INHERIT'}}, {'tag': 'group@', 'id': None, 'type': 'ALLOW', 'perms': {'BASIC': 'MODIFY'}, 'flags': {'BASIC': 'INHERIT'}}]}

I don't see this issue. Sorry if the chunk is somewhat illegible. Those are the middleware API calls to manipulate the ACL. Here is the case of a subdataset:

Code:

root@adtest[~]# zfs create dozer/SMB/subdataset
root@adtest[~]# python3                        
Python 3.7.5 (default, Nov 15 2019, 13:07:21) 
[Clang 8.0.0 (tags/RELEASE_800/final 356365)] on freebsd11
Type "help", "copyright", "credits" or "license" for more information.
>>> from middlewared.client import Client
>>> Client().call('filesystem.getacl', '/mnt/dozer/SMB/subdataset')
{'uid': 0, 'gid': 0, 'acl': [{'tag': 'owner@', 'id': None, 'type': 'ALLOW', 'perms': {'READ_DATA': True, 'WRITE_DATA': True, 'APPEND_DATA': True, 'READ_NAMED_ATTRS': True, 'WRITE_NAMED_ATTRS': True, 'EXECUTE': True, 'DELETE_CHILD': False, 'READ_ATTRIBUTES': True, 'WRITE_ATTRIBUTES': True, 'DELETE': False, 'READ_ACL': True, 'WRITE_ACL': True, 'WRITE_OWNER': True, 'SYNCHRONIZE': True}, 'flags': {'BASIC': 'NOINHERIT'}}, {'tag': 'group@', 'id': None, 'type': 'ALLOW', 'perms': {'READ_DATA': True, 'WRITE_DATA': False, 'APPEND_DATA': False, 'READ_NAMED_ATTRS': True, 'WRITE_NAMED_ATTRS': False, 'EXECUTE': True, 'DELETE_CHILD': False, 'READ_ATTRIBUTES': True, 'WRITE_ATTRIBUTES': False, 'DELETE': False, 'READ_ACL': True, 'WRITE_ACL': False, 'WRITE_OWNER': False, 'SYNCHRONIZE': True}, 'flags': {'BASIC': 'NOINHERIT'}}, {'tag': 'everyone@', 'id': None, 'type': 'ALLOW', 'perms': {'READ_DATA': True, 'WRITE_DATA': False, 'APPEND_DATA': False, 'READ_NAMED_ATTRS': True, 'WRITE_NAMED_ATTRS': False, 'EXECUTE': True, 'DELETE_CHILD': False, 'READ_ATTRIBUTES': True, 'WRITE_ATTRIBUTES': False, 'DELETE': False, 'READ_ACL': True, 'WRITE_ACL': False, 'WRITE_OWNER': False, 'SYNCHRONIZE': True}, 'flags': {'BASIC': 'NOINHERIT'}}]}
>>> new_acl = Client().call('filesystem.get_default_acl', 'RESTRICTED')
>>> Client().call('filesystem.setacl', {'path': '/mnt/dozer/SMB', 'dacl': new_acl, 'options': {'recursive': True, 'traverse': True}})
53
>>> Client().call('filesystem.getacl', '/mnt/dozer/SMB/subdataset')
{'uid': 0, 'gid': 0, 'acl': [{'tag': 'owner@', 'id': None, 'type': 'ALLOW', 'perms': {'BASIC': 'FULL_CONTROL'}, 'flags': {'BASIC': 'INHERIT'}}, {'tag': 'group@', 'id': None, 'type': 'ALLOW', 'perms': {'BASIC': 'MODIFY'}, 'flags': {'BASIC': 'INHERIT'}}]}

Or at least from what i see in midnight commander..permissions stay under the creator. (reviewing tons of folders via getfacl is impossible, i need a file manager for sure). The problem is i need to set up files for all users manually (create basic folders, restore backed up files), then i want to limit the access to actual users. I had a high hope ACL editor, working at least at the dataset level, could do this using recursivity.

If the goal is to change the owner UID and group GID, then you will need to alter the form from what it is currently showing. The reason for this is changing owner and group is generally not desirable for our enterprise user. File ownership can be like a fingerprint showing who created the file. If you change the owner, then the webui will send an API call with the appropriate UID, and file ownership will be changed.

Code:

>>> Client().call('filesystem.getacl', '/mnt/dozer/SMB/subdataset')
{'uid': 0, 'gid': 0, 'acl': [{'tag': 'owner@', 'id': None, 'type': 'ALLOW', 'perms': {'BASIC': 'FULL_CONTROL'}, 'flags': {'BASIC': 'INHERIT'}}, {'tag': 'group@', 'id': None, 'type': 'ALLOW', 'perms': {'BASIC': 'MODIFY'}, 'flags': {'BASIC': 'INHERIT'}}]}
>>> Client().call('filesystem.setacl', {'path': '/mnt/dozer/SMB', 'uid': 1000, 'dacl': new_acl, 'options': {'recursive': True, 'traverse': True}})
60
>>> Client().call('filesystem.getacl', '/mnt/dozer/SMB/subdataset')
{'uid': 1000, 'gid': 0, 'acl': [{'tag': 'owner@', 'id': None, 'type': 'ALLOW', 'perms': {'BASIC': 'FULL_CONTROL'}, 'flags': {'BASIC': 'INHERIT'}}, {'tag': 'group@', 'id': None, 'type': 'ALLOW', 'perms': {'BASIC': 'MODIFY'}, 'flags': {'BASIC': 'INHERIT'}}]}

The "recursive" checkbox applies the changes recursively inside the dataset. The "traverse" checkbox applies it to all child datasets.