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.
For example, the standard ugo/rwx permissions does not allow to set different permissions for different individual users or groups. With ACLs this is relatively easy to do, as we will see in this article.
Checking File System Compatibility with ACLs
To ensure that your file systems are currently supporting ACLs, you should check that they have been mounted using the acl option. To do that, we will use tune2fs for ext2/3/4 file systems as indicated below. Replace /dev/sda1 with the device or file system you want to check:
# tune2fs -l /dev/sda1 | grep "Default mount options:"
Note: With XFS, Access Control Lists are supported out of the box.
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:"
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 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.
Introducing ACLs in Linux
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 # useradd walterwhite # useradd saulgoodman # usermod -a -G developers walterwhite # usermod -a -G developers saulgoodman
Before we proceed, let’s verify that both users have been added to the developers group:
# id walterwhite # id saulgoodman
Let’s now create a directory called test in /mnt, and a file named acl.txt inside (/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 # touch /mnt/test/acl.txt # chgrp -R developers /mnt/test # chmod -R 770 /mnt/test
As expected, you can write to /mnt/test/acl.txt as walterwhite or saulgoodman:
# su - walterwhite # echo "My name is Walter White" > /mnt/test/acl.txt # exit # su - saulgoodman # echo "My name is Saul Goodman" >> /mnt/test/acl.txt # exit
So far so good. 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.
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. That is precisely where ACLs come in handy.
Setting ACL’s in Linux
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.
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.
Let’s give user gacanepa read and write access to /mnt/test/acl.txt. Before doing that, let’s take a look at the current ACL settings in that directory with:
# 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
And run getfacl on the file again to compare. The following image shows the “Before” and “After”:
# getfacl /mnt/test/acl.txt
Next, we will need to give others execute permissions on the /mnt/test directory:
# chmod +x /mnt/test
Keep in mind that in order to access the contents of a directory, a regular user needs execute permissions on that directory.
User gacanepa should now be able to write to the file. Switch to that user account and execute the following command to confirm:
# echo "My name is Gabriel Cánepa" >> /mnt/test/acl.txt
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 # getfacl /mnt/test/
The ACL above will allow users not in the owner group to have read access to the future contents of the /mnt/test directory. Note the difference in the output of getfacl /mnt/test before and after the change:
To remove a specific ACL, replace
-m in the commands above with
-x. For example,
# setfacl -x d:o /mnt/test
Alternatively, you can also use the
-b option to remove ALL ACLs in one step:
# setfacl -b /mnt/test
For more information and examples on the use of ACLs, please refer to chapter 10, section 2, of the openSUSE Security Guide (also available for download at no cost in PDF format).
Set Linux Disk Quotas on Users and Filesystems
Storage space is another resource that must be carefully used and monitored. To do that, quotas can be set on a file system basis, either for individual users or for groups.
Thus, a limit is placed on the disk usage allowed for a given user or a specific group, and you can rest assured that your disks will not be filled to capacity by a careless (or malintentioned) user.
The first thing you must do in order to enable quotas on a file system is to mount it with the usrquota or grpquota (for user and group quotas, respectively) options in /etc/fstab.
For example, let’s enable user-based quotas on /dev/vg00/vol_backups and group-based quotas on /dev/vg00/vol_projects.
Note that the UUID is used to identify each file system.
UUID=f6d1eba2-9aed-40ea-99ac-75f4be05c05a /home/projects ext4 defaults,grpquota 0 0 UUID=e1929239-5087-44b1-9396-53e09db6eb9e /home/backups ext4 defaults,usrquota 0 0
Unmount and remount both file systems:
# umount /home/projects # umount /home/backups # mount -o remount /home/projects # mount -o remount /home/backups
Then check that the usrquota and grpquota options are present in the output of mount (see highlighted below):
# mount | grep vg00
Finally, run the following commands to initialize and enable quotas:
# quotacheck -avugc # quotaon -vu /home/backups # quotaon -vg /home/projects
That said, let’s now assign quotas to the username and group we mentioned earlier. You can later disable quotas with quotaoff.
Setting Linux Disk Quotas
Let’s begin by setting an ACL on /home/backups for user gacanepa, which will give him read, write, and execute permissions on that directory:
# setfacl -m u:gacanepa:rwx /home/backups/
# edquota -u gacanepa
We will make the soft limit=900 and the hard limit=1000 blocks (1024 bytes/block * 1000 blocks = 1024000 bytes = 1 MB) of disk space usage.
We can also place a limit of 20 and 25 as soft and hard limites on the number of files this user can create.
The above command will launch the text editor ($EDITOR) with a temporary file where we can set the limits mentioned previously:
These settings will cause a warning to be shown to user gacanepa when he has either reached the 900-block or 20-inode limits for a default grace period of 7 days.
If the over-quota situation has not been eliminated by then (for example, by removing files), the soft limit will become the hard limit and this user will be prevented from using more storage space or creating more files.
To test, let’s have user gacanepa try to create an empty 2 MB file named test1 inside /home/backups:
# dd if=/dev/zero of=/home/backups/test1 bs=2M count=1 # ls -lh /home/backups/test1
As you can see, the write operation file fails due to the disk quota having been exceeded. Since only the first 1000 KB are written to disk, the result in this case will most likely be a corrupt file.
Similarly, you can create an ACL for the developers groups in order to give members of that group rwx access to /home/projects:
# setfacl -m g:developers:rwx /home/projects/
And set the quota limits with:
# edquota -g developers
Just like we did with user gacanepa earlier.
The grace period can be specified for any number of seconds, minutes, hours, days, weeks, or months by executing.
# edquota -t
and updating the values under Block grace period and Inode grace period.
As opposed to block or inode usage (which are set on an user or group-basis), the grace period is set system-wide.
To report quotas, you can use quota
-u [user] or
quota -g [group] for a quick list or
repquota -v [/path/to/filesystem] for a more detailed (verbose) and nicely formatted report.
Of course, you will want to replace
[/path/to/filesystem] with specific user / group names and file system you want to check.
In this article we have explained how to set Access Control Lists and disk quotas for users and groups. Using both, you will be able to manage permissions and disk usage more effectively.
If you want to learn more about quotas, you can refer to the Quota Mini-HowTo in The Linux Documentation Project.
Needless to say, you can also count on us to answer questions. Just submit them using the comment form below and we will be more than glad to take a look.
15 thoughts on “How to Set Access Control Lists (ACL’s) and Disk Quotas for Users and Groups”
I’m very sorry for English. I use google translation.
My problem is I installed zentyal 6.1, I created domain and users. windows machines domain extension is successful, but I want to share files. I create all privileges in file sharing, as a user, and as a group.
Although Windows computers are in the domain, when I try to enter shared folders, I am not authorized to give an element not found.
can you please help?
Thank you so much
[email protected]:/home/samba/shares# getfacl Kalite
# file: Kalite
# owner: root
# group: adm
default:group:IZOPEK\134domain\040admins:rwx ? = 134domain\040admins group = domain admins
default:group:IZOPEK\134pazarlama:rwx ? = 134pazarlam group = pazarlama
Thanks greatly for your this article. You’re one of the best.
I tried to implement this in VirtualBox but with partial success – the usrquota worked perfectly but the grpquota does not, I have tried severally without success and searched online for any successful implementation of grpquota but found none.
I would appreciate it if you go through some excerpts from my work pasted below. Could you tell why this user (udo) who is a member of testgrp group could exceed quota? I think the files created by udo (user) in that directory (/adihome/aditec) should belong to tesgrp (recursively made the directory).
Thanks in advance.
This was very helpful ..thanks
You raised an important point. As a general rule, you can access the contents of a directory if and only if you have execute permission on it. So yes, you were right. In the box I used to write this article, user gacanepa had been left as member of the developers group because even though I removed it, I did not log out and log back in to apply changes. My bad. Great catch!
I’ll send you the needed correction via email.
Thanks a lot for nice and useful article
I am glad to hear that you found this article useful. Make sure you add it to your bookmarks and share!
Thanks for taking a minute to show your appreciation for your work. Feel free to share :).
Gabriel I think there must be gap when we try setfacl ganacepa it is not working permission denied..pls explain
Did you enable ACLs? Did you follow the steps outlined in this article? Please provide the exact command (complete) where you are experiencing your error and the exact message.
Not working for me either :/ double checked all commands, and nothing.. I have ACL’s enabled for this file system.
@gagan and @Nuno,
It is working just fine for me. Please refer to this image for details: http://tinypic.com/view.php?pic=11w4whl&s=9
Not working here. Could you please check if your user gacanepa is not a member of developers group? With my current settings I cant even auto complete the filename with tab, which means that I don’t have permissions even for reading the file.
I think I found the problem. For this to work, I have to give execution rights to others on the parent directory test for the user to be able to read directory content independently of the ACL rule. Otherwise it doesn’t work.
sudo chmod -R 775 /mnt/test OR sudo chmod -R 771 /mnt/test
nice tips, thanks :)