The ACL above will allow users not in the owner group to have read access to the future contents of the /mnt/test directory. To set a default ACL to a directory (which its contents will inherit unless overwritten otherwise), add d: before the rule and specify a directory instead of a file name: # setfacl -m d:o:r /mnt/test

Switch to that user account and execute the following command to confirm: # echo 'My name is Gabriel Cánepa' > /mnt/test/acl.txt User gacanepa should now be able to write to the file. Keep in mind that in order to access the contents of a directory, a regular user needs execute permissions on that directory. Next, we will need to give others execute permissions on the /mnt/test directory: The following image shows the “Before” and “After”: # getfacl /mnt/test/acl.txt Then change the ACLs on the file, use u: followed by the username and :rw to indicate read / write permissions: # setfacl -m u:gacanepa:rw /mnt/test/acl.txtĪnd run getfacl on the file again to compare. Before doing that, let’s take a look at the current ACL settings in that directory with: # getfacl /mnt/test/acl.txt Let’s give user gacanepa read and write access to /mnt/test/acl.txt. If files inside a directory where a default ACL has been set do not have a ACL of their own, they inherit the default ACL of their parent directory. There are two types of ACLs: access ACLs are (which are applied to a file or directory), and default (optional) ACLs, which can only be applied to a directory. That is precisely where ACLs come in handy. Standard ugo/rwx permissions would require that the new user be added to the developers group, but that would give him/her the same permissions over all the objects owned by the group. However, we will soon see a problem when we need to grant write access to /mnt/test/acl.txt for another user that is not in the developers group. # echo 'My name is Saul Goodman' > /mnt/test/acl.txt # echo 'My name is Walter White' > /mnt/test/acl.txt Then we will set the group owner to developers and change its default ugo/rwx permissions recursively to 770 (thus granting read, write, and execute permissions granted to both the owner and the group owner of the file): # mkdir /mnt/testĪs expected, you can write to /mnt/test/acl.txt as walterwhite or saulgoodman: # su - walterwhite

Let’s now create a directory called test in /mnt, and a file named acl.txt inside ( /mnt/test/acl.txt). To illustrate how ACLs work, we will use a group named developers and add users walterwhite and saulgoodman (yes, I am a Breaking Bad fan!) to it.: # groupadd developersīefore we proceed, let’s verify that both users have been added to the developers group: # id walterwhite In that case, remove it, unmount the file system, and then mount it again, or simply reboot your system after saving the changes to /etc/fstab. If the above command does not indicate that the file system has been mounted with support for ACLs, it is most likely due to the noacl option being present in /etc/fstab. In the following ext4 file system, we can see that ACLs have been enabled for /dev/xvda2: # tune2fs -l /dev/xvda2 | grep 'Default mount options:'

Note: With XFS, Access Control Lists are supported out of the box. Replace /dev/sda1 with the device or file system you want to check: # tune2fs -l /dev/sda1 | grep 'Default mount options:' To do that, we will use tune2fs for ext2/3/4 file systems as indicated below. To ensure that your file systems are currently supporting ACLs, you should check that they have been mounted using the acl option. Checking File System Compatibility with ACLs With ACLs this is relatively easy to do, as we will see in this article. Access Control Lists (also known as ACLs) are a feature of the Linux kernel that allows to define more fine-grained access rights for files and directories than those specified by regular ugo/rwx permissions.įor example, the standard ugo/rwx permissions does not allow to set different permissions for different individual users or groups.

Setfacl not setting defaults