setfacl recursive quick and dirty, how?

[panz]

I need to change the permissions of a directory recursively, but the man page of setfacl doesn't explain how...

 

[dlavigne]

Is this UNIX or Windows permissions? How is that directory being shared, by CIFS?

 

[panz]

CIFS shared ZFS dataset

[root@freenas] /mnt/tank1/jails/plex_1/media# getfacl documentaries
# file: documentaries
# owner: panz
# group: panz
owner@:rwxpD-aARWcCo-:------:allow
group@:rwxpD-a-R-c---:------:allow
everyone@:r-x---a-R-c---:------:allow
group@:rwxpDdaARWcCo-:fd----:allow
owner@:rwxpDdaARWcCo-:fd----:allow

setfacl man page lists different switches for POSIX.1e ACLs and for NFSv4 ACLs; don't know which type FreeNAS-Samba is using.

 

[dlavigne]

Shouldn't you be using setacl on the Windows side instead of setfacl on the FreeNAS side? Permissions are meant to be fine-tuned on the client.

 

[panz]

I explained this problem in another thread of mine:

http://forums.freenas.org/threads/permissions-extended-acls-and-plex-jail-getfacl.16091/

If you use plex media server plugin, you're forced to setup a jail (and now FreeNAS v. 9.1.1 does it for you).

But - right after plugin installation - you can't see any shared media file. Why? Because of permissions.

So you go into your Plex jail and chmod 777 the linked media directory. This is an operation - you know - that you can't accomplish from your shared directory via GUI from Windows or whatever OS you use. You have to do that from the command line, because the (buggy?) plugin installer doesn't do that for you (and now I can say that I don't like to chmod 777 any directory only to use a stupid media sharing server... but this is another story).

 

[Dusan]

You can run [PANEL]find <directory>/ -exec setfacl <your_options> {} \; [/PANEL] to recursively apply the same options to all files & directories in (and including) <directory> (the directory path needs to end with a forward slash so I included it above).
If you have different setting for directories and files you can run:
[PANEL]find <directory>/ -type f -exec setfacl <file_options> {} \;
find <directory>/ -type d -exec setfacl <directory_options> {} \;[/PANEL]
Reference: http://www.freebsd.org/cgi/man.cgi?query=find

 

[cyberjock]

But - right after plugin installation - you can't see any shared media file. Why? Because of permissions.

So you go into your Plex jail and chmod 777 the linked media directory. This is an operation - you know - that you can't accomplish from your shared directory via GUI from Windows or whatever OS you use. You have to do that from the command line, because the (buggy?) plugin installer doesn't do that for you (and now I can say that I don't like to chmod 777 any directory only to use a stupid media sharing server... but this is another story).

I wouldn't say that the installer is buggy at all. You don't want an installer chosing the wrong directory and/or setting the wrong permissions. Permissions should be controlled by a human being(the server admin most perferably). There's plenty of way to slay this beast without doing 777. You just have to understand and apply permissions appropriately. Generally speaking, when someone does 777 they're doing more of a "just make this crap work for me" than strategically setting up and assigning appropriate permissions.

 

[Neme]

First of all im no expert in this but i have got them working to my satisfaction (and securely) on my FreeNAS 9.1.1 server.

Out of interest are you trying to use ACLs on a UFS or ZFS volume?

Reason I ask is that I believe NFSv4 inherritance doesn't work as you might expect on UFS. I tried it, failed and then found sources online that state this is the case (such as https://wiki.freebsd.org/NFSv4_ACLs right at the bottom). On ZFS i have found things to work fine, to give some usefull examples for the commands provided by Dusan:

Code:

find /mnt/ZFS1/test/ -type d -exec setfacl -m u:John:modify_set:fd:allow {} \;

Would recursively set modify permissions for user "John" on the folder /mnt/ZFS1/test/ and all sub folders, this also specifies file and folder inheritance for these permissions (this will only affect files/folders moved into or created in these folders from this point forward)

Code:

find /mnt/ZFS1/test/ -type f -exec setfacl -m u:John:modify_set:allow {} \;

Does the same as above but recursively for files in /mnt/ZFS1/test/ (obviously no inheritance settings are required)

Change u: to g: for groups, -m to -x to remove ACL entries instead of create/modify.

You can set individual permissions using the letter codes (see below), however these commonly required ones are also available:

• full_set all permissions
• modify_set all permissions except write_acl and write_owner
• read_set read_data, read_attributes, read_xattr and read_acl
• write_set write_data, append_data, write_attributes and write_xattr

Code:

        owner@:--------------:-------:deny
        owner@:rwxp---A-W-Co-:-------:allow
        group@:-w-p----------:-------:deny
        group@:r-x-----------:-------:allow
     everyone@:-w-p---A-W-Co-:-------:deny
     everyone@:r-x---a-R-c--s:-------:allow
               ||||||||||||||:|||||||
  (r)read data +|||||||||||||:||||||+ (I)nherited
  (w)rite data -+||||||||||||:|||||+- (F)ailed access (audit)
     e(x)ecute --+|||||||||||:||||+-- (S)uccess access (audit)
      a(p)pend ---+||||||||||:|||+--- (n)o propagate
      (d)elete ----+|||||||||:||+---- (i)nherit only
(D)elete child -----+||||||||:|+----- (d)irectory inherit
 read (a)ttrib ------+|||||||:+------ (f)ile inherit
write (A)ttrib -------+||||||
  (R)ead xattr --------+|||||
 (W)rite xattr ---------+||||
    read a(c)l ----------+|||
   write a(C)l -----------+||
change (o)wner ------------+|
          sync -------------+

That should cover the basics, any questions please ask :)

 

[panz]

I wouldn't say that the installer is buggy at all. You don't want an installer chosing the wrong directory and/or setting the wrong permissions. Permissions should be controlled by a human being(the server admin most perferably). There's plenty of way to slay this beast without doing 777. You just have to understand and apply permissions appropriately. Generally speaking, when someone does 777 they're doing more of a "just make this crap work for me" than strategically setting up and assigning appropriate permissions.

I completely agree with you. But I tried to make that plugin to work in, perhaps, fifteen different manners and I failed. Only chmod 777 to the plugin's media dir (which is a link, so you change the permissions to the actual media directory outside the jail...) gained the desired results.

 

[bluonek]

Sorry to necro (hard), but I've been looking for @Neme's post for four years (basically =).

It was time to re-think how I was doing permissions on my FreeNAS box w/ approx 4TB of data. Handling this in Windows was no longer an option. It was too slow and when errors came up, they came in droves of popup confirmations.

While I used setfacl/getfacl in the past, the usage was limited and mostly unsure. @Neme's post ended that unsure-ness, and summarized the long-winded and confusing man pages.

IMHO this should be in the handbook as it covers quite clearly how 99% (?) FreeNAS users would use setfacl/getfacl if indeed Windows GUI was not going to work for them.

Thanks @Neme!