SOLVED setfacl fails with invalid argument

[techmattr]

So I'm trying to set everyone full access on a Windows share. The GUI doesn't seem to allow setting permissions. It defaults to 775 no matter what.

So I'm trying to use setfacl to update the everyone user and no matter what I use for -m entries it throws Invalid argument.

Code:

[root@freenas01] /mnt/dlvol1# getfacl dldataset1/
# file: dldataset1/
# owner: root
# group: wheel
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:r-x---a-R-c---:fd-----:allow

Code:

setfacl -m u:everyone@:rwx dldataset1

This is as simple as I can make the command and it still fails...

Code:

setfacl: u:everyone@:rwx: Invalid argument

Any help would be greatly appreciated.

 

[techmattr]

Found the answer....

Code:

setfacl -m everyone@:full_set:fd:allow dldataset1

This command works. Apparently with FreeNAS the setfacl command doesn't like u: for the user qualifier. I tried in a live ISO FreeBSD 10.3 and the u: worked fine. Not sure what the difference could be. I could have the wrong FreeBSD version or something.

This will only set the permissions on the given object though... and FreeNAS9.1/FreeBSD 10.3 doesn't have a recursive option in setfacl for some reason. So you have to set perms on all dirs then all files. New files and dirs should work fine.

cd to the dir where you want all subobjects to be modified.

Code:

[root@freenas01] /mnt/dlvol1/dldataset1# find . -type d -exec setfacl -m everyone@:full_set:fd:allow {} \;
[root@freenas01] /mnt/dlvol1/dldataset1# find . -type f -exec setfacl -m everyone@:full_set::allow {} \;

Pretty janky method but it worked perfectly for setting perms to have a wide open Windows share.

For reference the regular UNIX 777 perms were working just fine until I tried to edit an mp3 tag or mkv header. For some reason I couldn't open files for editing. I could delete and add fine but couldn't live edit files. All that works flawlessly now.

references:
https://forums.freenas.org/index.ph...allowing-applications-write-permission.18854/
http://vladvasiliu.com/post/2013-08-17_03-setting_default_nfsv4_acls_on_freebsd.html

 

[Nick2253]

You should be able to do all this with the GUI, or at least accomplish what you're trying to accomplish with the GUI.

How do you have the dataset configured? Is it using Windows permissions?

 

[Jurgen Segaert]

What Nick says. It's not needed or recommended to mess with the ACL settings at the CLI-level.

Please take a look at anodo's guide for setting permissions on CIFS shares.
The "Apply default permissions" checkbox that shows up when creating a Windows CIFS share, sets the 775.
You can/should then fine-tune your permissions using Windows Explorer (as in step #7 of the guide); just give the "Everyone" group all access.

 

[techmattr]

Yeah but even in that guide it shows the "bug" I'm experiencing. I know I've seen it mentioned many times before as well. When you set Windows permissions on a dataset through the GUI you can't set permission for full control for everyone. If you look at step 4 in that guide you can see the guest/world permissions set to Read, Execute. Setting up a user on the Windows and FreeNAS with the same name is a workaround but it shouldn't be needed. If the permission would just apply correctly when you set them in the GUI you could easily have a wide open share without having to setup additional users for no reason.

 

[Mirfster]

Look over @m0nkey_ 's vids. They should help you: https://www.youtube.com/channel/UCbLdnVTcjA0n23ZcPeUMzLA

 

[techmattr]

This is my end result and exactly what I wanted:

I haven't seen any guides or videos that show you can do this through the GUI. In a home environment on a media share or download share most people just use wide open perms. There is no reason to not have that option available through the GUI. The managing permissions through Windows thing is very FreeNAS specific. I've never seen any other NAS software expect permissions to be managed via client. QTS, DSM, Isilon, Data ONTAP, etc... all manage permissions within it's own management utilities with no dependency on client side configuration.

Edit: Let me clarify my point... FreeNAS needs to use the ACL file to set the owner and group anyway... so why not just manage the ACL properly via the GUI? I didn't realize at first that FreeNAS was almost completely hands off when using the Windows type and that is very odd and not done by any other NAS OS that I've seen.

 

[Mirfster]

The managing permissions through Windows thing is very FreeNAS specific.

Beg to differ... That is pretty much exactly how it is done in an Enterprise Environment. Initial Shares and Rights are setup by Domain Admins and after that pretty much all the other rights are done via Windows Explorer, RSAT, Command Line, PowerShell, etc.. (using appropriate credentials).

Think of it this way, you are a Domain Admin and have access/control over everything. Now you higher some "underlings" to take care of the small stuff (Password Resets, Create New Users, Delete Users, Assign Share Permissions, etc..).

So instead of granting them "Domain Admin" Rights, you create a group called "Domain Admin Underlings". Assign that Group just the rights it needs and toss in the User Accounts you wish to have ability to handle those tasks. Now, they can do what is required without needing to actually RDP to your Domain Controller(s) and can't muck around with other stuff they shouldn't be messing with in the first place (DNS, GPOs, DHCP, Server Roles, etc..).

 

[techmattr]

Beg to differ... That is pretty much exactly how it is done in an Enterprise Environment. Initial Shares and Rights are setup by Domain Admins and after that pretty much all the other rights are done via Windows Explorer, RSAT, Command Line, PowerShell, etc.. (using appropriate credentials).

Think of it this way, you are a Domain Admin and have access/control over everything. Now you higher some "underlings" to take care of the small stuff (Password Resets, Create New Users, Delete Users, Assign Share Permissions, etc..).

So instead of granting them "Domain Admin" Rights, you create a group called "Domain Admin Underlings". Assign that Group just the rights it needs and toss in the User Accounts you wish to have ability to handle those tasks. Now, they can do what is required without needing to actually RDP to your Domain Controller(s) and can't muck around with other stuff they shouldn't be messing with in the first place (DNS, GPOs, DHCP, Server Roles, etc..).

Yeah a storage admin would assign those groups permissions within the NAS OS when provisioning a share. Some NAS OS's have mmc's so that you can manage them through Windows but that it technically still being managed on the NAS OS. With Active Directory accounts it's a bit different since the account owner is going to be an AD account to begin with. The ability to change permissions is going to be possible from wherever you can access any given volume. You also have the option of importing everything into something like SCCM and centrally manage everything. However, for a standard file share NAS deployment you're going to manage everything from the NAS. In other NAS OS's though you're not hacking around with UNIX permissions trying to get the result you want. You have a GUI based ACL where you can modify everything right there.

 

[Jurgen Segaert]

This is my end result and exactly what I wanted...

Thank you for the screenshot. Yes, it does indeed always default to 775 in "step 4", but once you add "Full Control" in Window Explorer and revisit that screen, you see the same end result.

"Step 4"

Set "Full control" for Everyone from "Read & execute"

Check dataset permissions again: same end result.

Did this process for you still throw ACL errors?

This is a fairly painless process, and no command line is needed. The windows CIFS permissions are more elaborate than just the Read/Write/Execute, so I think it makes sense to tweak these settings in the more specialized screens of Win Explorer.

 

[techmattr]

Yeah those steps will work as long as you create a user in Windows and FreeNAS with matching user names and passwords in both environment. The steps go through this so if you follow the guide it will work. Otherwise no, that won't work. You'll get Access Denied. As you should. Creating the two users IMO is a workaround. Using Active Directory is the proper solution to this but that isn't always the most reasonable path in home use.

My problem with this two user process is that I just don't want to create an extra user to set permissions. It's just not necessary when the tools exist in the NAS OS already.

 

[anodos]

Yeah but even in that guide it shows the "bug" I'm experiencing. I know I've seen it mentioned many times before as well. When you set Windows permissions on a dataset through the GUI you can't set permission for full control for everyone. If you look at step 4 in that guide you can see the guest/world permissions set to Read, Execute. Setting up a user on the Windows and FreeNAS with the same name is a workaround but it shouldn't be needed. If the permission would just apply correctly when you set them in the GUI you could easily have a wide open share without having to setup additional users for no reason.

I am unaware of any acl related bugs. Many apparent 'bugs' are related to users setting the share type to 'unix' on Windows shares or manually changing POSIX mode bits. There are also a decent amount of 'bugs' caused by cached credentials and old drive maps.

Guest access should probably be set using samba's 'guest' parameters.

 

[anodos]

My problem with this two user process is that I just don't want to create an extra user to set permissions. It's just not necessary when the tools exist in the NAS OS already.

My home computers always have two users (local admin account and limited day-to-day user account) :)

There's no need to create a dedicated admin user on the NAS. The dataset owner is automatically granted full control and can fine-tune permissions as needed.