Linux Command #52 – getfacl (Linux OS)

Anime-style illustration of a Black Linux administrator reviewing getfacl ACL output in a server room with a Tux figurine.

getfacl displays the Access Control List attached to a Linux file or directory. It is the natural follow-up to Linux Command #51 – umask, because default ACLs can change the permissions newly created files receive even when the shell’s umask appears straightforward.

What getfacl shows

Run getfacl FILE or getfacl DIRECTORY. The command prints the object’s owner, group, and ACL entries. According to the Linux manual, it displays the access ACL for every file and also displays a directory’s default ACL when one exists. Regular files cannot have default ACLs.

A basic ACL can resemble the familiar owner, group, and other permissions. Extended ACLs can add named users, named groups, a mask entry, and—on directories—default entries that influence newly created objects.

Red Hat community ACL terminal example showing getfacl output for named users and an ACL mask.
A real Red Hat community troubleshooting example shows how getfacl exposes named-user entries, group permissions, and the ACL mask.

Read a simple ACL

If getfacl report.txt prints user::rw-, group::r--, and other::---, those three entries correspond closely to the traditional permission bits you already learned with Linux Command #50 – chmod.

If the output also contains something like user:alice:r--, that is a named-user ACL entry granting Alice explicit permissions without changing the file’s owner or primary group. If ls -l shows a trailing + after the permission string, that is a strong clue that an extended ACL is present.

This hands-on Linux ACL walkthrough demonstrates getfacl, setfacl, named entries, masks, and default ACL behavior.

The ACL mask is a ceiling

The mask:: entry is one of the most important lines in extended ACL output. The Linux manual explains that the mask limits the effective rights of named users, the owning group, and named groups. The file owner and the other entry are not limited by that ACL mask.

That means an entry can appear to grant rwx while the effective permission is smaller. When this happens, getfacl can print an #effective: comment beside the affected entry. Do not troubleshoot only from the entry itself—read the mask too.

A #100DaysOfDevOps ACL exercise shows Linux ACL management in practical automation work.

Inspect default ACLs

Run getfacl DIRECTORY on a directory that uses inherited permissions. Entries beginning with default: describe the ACL template used when new files or subdirectories are created there. The Linux ACL manual distinguishes this default ACL from the directory’s own access ACL.

This is where getfacl connects back to umask. A default ACL can alter the resulting permissions of newly created objects, so if file permissions do not match what you predicted from the current mask, inspect the parent directory’s default ACL before assuming the mask is wrong.

Useful read-only options

  • getfacl FILE — show the file’s ACL.
  • getfacl DIRECTORY — show the directory’s access ACL and any default ACL.
  • getfacl -a FILE — display only the access ACL.
  • getfacl -d DIRECTORY — display the default ACL.
  • getfacl -c FILE — omit the comment header.
  • getfacl -n FILE — show numeric user and group IDs instead of names.
  • getfacl -R DIRECTORY — inspect ACLs recursively. Use this carefully on large trees because the output can be extensive.

The command is primarily an inspection tool; it does not modify the ACL. The companion command that changes ACLs is setfacl, which will be covered separately.

Troubleshooting example

Suppose a user says, “The file shows read permission for me, but access still fails.” Start with ls -l FILE, then run getfacl FILE. Check the named user or group entry, the mask:: line, and every parent directory’s execute/search permission. ACLs do not bypass the need to traverse the directory path.

Also remember that ownership still matters. Linux Command #49 – chown changes ownership, while getfacl reads the more detailed access rules layered on top of the traditional model.

Practice lab

  1. Create a disposable file with touch acl-lab.txt.
  2. Run ls -l acl-lab.txt and record the ordinary permission bits.
  3. Run getfacl acl-lab.txt and identify the owner, group, and other entries.
  4. Run getfacl -c acl-lab.txt and compare the shorter output.
  5. Create a disposable directory and run getfacl -d DIRECTORY. Explain what it means if no default ACL entries appear.
  6. Do not modify system ACLs during this exercise.

Knowledge check

  1. What does getfacl display?
  2. Can a regular file have a default ACL?
  3. What does the ACL mask limit?
  4. What does a trailing + in ls -l usually indicate?
  5. Which companion command modifies ACL entries?

Answer guide

  1. The access ACL of a file or directory, plus the default ACL when the target is a directory that has one.
  2. No. Default ACLs belong to directories.
  3. The effective permissions of named users, the owning group, and named groups.
  4. That extended ACL information is associated with the object.
  5. setfacl.

Key takeaway

When ordinary chmod permissions do not explain who can access a file, run getfacl. It exposes named users, named groups, ACL masks, and inherited default rules that are invisible in the basic owner/group/other model.


Advertisement

Follow BitcoinVersus.Tech for independent technology reporting and open-source technical education.

BitcoinVersus.Tech Editor’s Note:

We volunteer daily to ensure the credibility of the information on this platform is Verifiably True. If you would like to support to help further secure the integrity of our research initiatives, please donate here: 3C9o19EH5HSiwEPyCTmEKzxhNCbo2X6TTb

BitcoinVersus.tech is not a financial advisor. This media platform reports on financial subjects purely for informational purposes.

Leave a Reply