Updated: 12 October 2026 · Applies to: acl 2.3.2 tested on Debian 13 with Linux 6.12 (ext4 and XFS); the same setfacl and getfacl commands work on Ubuntu 24.04 and 26.04, AlmaLinux and Rocky Linux 9 and 10

A Linux ACL (access control list) gives extra users and groups their own permissions on a file or folder, on top of the normal owner, group and others. Add one with setfacl -m u:alice:rwx /path, read it with getfacl /path and remove it with setfacl -x u:alice /path. The owner and group do not change. On current kernels ACLs work on ext4, XFS and Btrfs without any mount option.

A typical case: a website folder belongs to www-data, and a deploy user also needs to write to it. With plain chmod you would have to change the group or make the folder writable for everyone; an ACL gives that one user write access and nothing else.

Before you start

  • setfacl and getfacl come from the acl package: sudo apt install acl (Debian, Ubuntu) or sudo dnf install acl (AlmaLinux, Rocky Linux). Minimal and container images often lack it. If you get setfacl: command not found or Operation not supported, see setfacl command not found and Operation not supported.
  • You do not need acl in /etc/fstab. Since Linux 6.1, ext4 always has ACLs on and no longer accepts noacl: on our Linux 6.12 test kernel, mount -o noacl failed with ext4: Unknown parameter 'noacl'. XFS has no ACL mount option at all.
  • Only the file’s owner or root can change its ACL, so most commands below need sudo.

The output below is from our test lab: an ext4 file system, the users alice and bob, and a group developers.

1. Give a user access with setfacl -m

The folder belongs to www-data with mode 755, so alice cannot write to it:

$ ls -ld /srv/www/site
drwxr-xr-x 2 www-data www-data 1024 Oct 11 15:28 /srv/www/site
$ touch /srv/www/site/deploy.txt
touch: cannot touch '/srv/www/site/deploy.txt': Permission denied

Give alice read, write and enter rights on the folder:

sudo setfacl -m u:alice:rwx /srv/www/site

After that, alice’s touch works. The rule format is u:USER:PERMS for a user, g:GROUP:PERMS for a group, m::PERMS for the mask and o::PERMS for others. Several rules go in one command, separated by commas: setfacl -m u:alice:rwx,g:developers:rx /srv/project. A user or group that does not exist gives Option -m: Invalid argument near character 3.

2. Read the ACL with getfacl and ls -l

$ getfacl -p /srv/www/site
# file: /srv/www/site
# owner: www-data
# group: www-data
user::rwx
user:alice:rwx
group::r-x
mask::rwx
other::r-x

$ ls -ld /srv/www/site
drwxrwxr-x+ 2 www-data www-data 1024 Oct 11 15:28 /srv/www/site
  • user:: is the owner, group:: the owning group and other:: everyone else: the normal permissions.
  • user:alice: and group:NAME: lines are the extra ACL entries.
  • mask:: is the most that named users and groups can get (section 5).
  • The + at the end of the permissions in ls -l means the file has an ACL. With an ACL, the middle (group) part of ls -l shows the mask.

Without -p, getfacl prints the harmless note Removing leading '/' from absolute path names.

3. Apply it to files that already exist

An ACL on a folder does not change the files inside it. Alice could create files, but appending to the existing index.html still gave Permission denied. Apply the rule recursively:

sudo setfacl -R -m u:alice:rwX /srv/www/site

The capital X gives execute only to folders and to files that are already executable, so text files do not become executable.

4. Make new files inherit access (default ACL)

A default ACL on a folder is copied to every new file and subfolder created inside it:

sudo setfacl -R -d -m u:alice:rwX /srv/www/site
sudo setfacl -R -d -m g:www-data:rwX /srv/www/site

-d works only on folders; with -R, setfacl applies it to every subfolder and skips files. Then the web server (as www-data) created upload.txt:

$ getfacl -p /srv/www/site/upload.txt
# file: /srv/www/site/upload.txt
# owner: www-data
# group: www-data
user::rw-
user:alice:rwx			#effective:rw-
group::r-x			#effective:r--
group:www-data:rwx		#effective:rw-
mask::rw-
other::r--

Alice can edit the new file without anyone running setfacl again. #effective shows the rights that really apply: programs create normal files without execute permission, so the mask is rw-. New subfolders get the default ACL too, so it keeps working further down. When a folder has a default ACL, the default ACL takes the place of the umask for new files (acl manual page): upload.txt came out as -rw-rw-r--+ although the process had umask 022.

5. The mask: why a user gets less than you set

chmod on a file with an ACL changes the mask. After chmod 640, alice lost write access although her own entry still says rw-:

$ sudo chmod 640 /srv/www/site/index.html
$ getfacl -p --omit-header /srv/www/site/index.html
user::rw-
user:alice:rw-			#effective:r--
group::r--
mask::r--
other::---

Fix it by setting the mask with sudo setfacl -m m::rw /srv/www/site/index.html, or by running your setfacl -m u:alice:rw command again: setfacl recalculates the mask each time unless you add -n. Keep this in mind for scripts that run chmod -R over a site after a deploy.

6. A user entry beats a group entry

According to the acl manual page, Linux checks in this order and stops at the first match: the owner, then named users, then the owning group and named groups, then others. So a user entry overrides any group the user is in. In our lab, bob is in developers, which has read access to /srv/project:

$ cat /srv/project/plan.txt
secret
$ sudo setfacl -m u:bob:--- /srv/project/plan.txt
$ cat /srv/project/plan.txt
cat: /srv/project/plan.txt: Permission denied

That is how you shut out one member of a group without removing them from it.

7. Remove ACL entries

sudo setfacl -x u:bob /srv/project/plan.txt        # remove one entry
sudo setfacl -x g:developers /srv/project          # remove a group entry
sudo setfacl -x d:u:alice /srv/www/site            # remove one default entry
sudo setfacl -k /srv/www/site                      # remove the whole default ACL
sudo setfacl -R -b /srv/project                    # remove all ACL entries

After -b, ls -l shows no + and only the normal permissions remain.

8. Back up, restore and copy ACLs

Save every ACL under a folder to a text file, and restore it from the same working folder (the file stores relative paths):

cd /srv
sudo getfacl -R www > /root/www-acls.txt
sudo setfacl --restore=/root/www-acls.txt

In our test we removed all ACLs with setfacl -R -b www, and --restore brought them back. Copy tools do not all keep ACLs. What we got when copying a file that had an ACL:

  • cp file: ACL lost. cp -p and cp -a: kept (GNU cp preserves ACLs together with the mode).
  • rsync -a: ACL lost. rsync -aA: kept.
  • tar: kept only with --acls both when creating and when extracting the archive.
  • mv within the same file system: kept.

More on copying with ownership and modes: copy files with permissions in Linux.

ACL or chmod?

Use normal permissions when one owner and one group are enough: see chmod 755, 644 and 600 explained and change ownership with chown. Use an ACL when one or two extra users or groups need access and you do not want to change the owner, the group or the rights of everyone else. Keep ACLs few and simple, because they are easy to forget: ls -l only shows a small +.

Official documentation: setfacl(1), getfacl(1) and acl(5).

Ucartz services for this topic

Was this answer helpful? 0 Users Found This Useful (0 Votes)