# getfacl

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/getfacl

## Quick definition

getfacl is a command used in Linux and Unix systems to show detailed permission information for files and directories. It reveals which users and groups have access and what they can do, like read, write, or execute. This is useful when basic permissions are not enough and more fine-grained control is needed.

## Simple meaning

Imagine you have a shared house with multiple roommates. The basic rule is that the owner of a room (the user), a group of roommates, and everyone else each have certain permissions: maybe the owner can enter and rearrange furniture, the group can enter but not rearrange, and everyone else is locked out. That is like the standard read, write, execute permissions in Linux. But what if you want to let one specific roommate borrow your laptop but keep everyone else out? The basic permission system cannot handle that alone. This is where Access Control Lists, or ACLs, come in. They are like a guest list for your room that you can write specific names on. The command 'getfacl' is like reading that guest list. It shows you exactly who has access, what they are allowed to do, and any special rules you have set. For example, you might have a file that everyone in your team can read, but only the project lead can edit. getfacl will show you that the project lead has read and write permissions, while the rest of the team only has read. It can also show default permissions for new files created inside a folder, like telling the house that any new furniture placed in the living room should automatically be accessible to all roommates. In short, getfacl is the tool that makes the invisible list of detailed permissions visible to you, so you can understand and troubleshoot who can do what on your system.

In the world of IT, systems often hold sensitive data, and you need to control access with precision. Standard permissions only let you set permissions for one user, one group, and everyone else. That is like having a door with three keys: one for the owner, one for a group, and one master key for everybody. But in a company, you might have a file that the sales team can read, the finance team can edit, and the manager can delete. With standard permissions, this is impossible. ACLs let you attach a list of multiple users and groups, each with their own permissions. The getfacl command is how you view that list. It shows you the owner, the owning group, the standard permissions, and then any additional ACL entries. Each entry tells you a user or group name and what they are allowed to do. This is essential for system administrators who need to verify that security policies are correctly applied, for auditors who need to check compliance, and for troubleshooting when someone cannot access a file they should be able to, or worse, when someone has access they should not.

## Technical definition

getfacl is a command-line utility on Linux and Unix-like operating systems that retrieves and displays the Access Control Lists (ACLs) associated with files and directories. It is part of the ACL (Access Control List) package, which also includes setfacl for setting ACLs. The command reads the extended attributes of the file system, specifically the ACL entries stored in the inode or extended attribute area, depending on the file system type (e.g., ext2/3/4, XFS, Btrfs, NFSv4). The output shows the file name, owner, group, and then the standard POSIX permissions (user, group, other) followed by any additional ACL entries.

The standard output format of getfacl includes the following sections: the file name, the owner and group, the base ACL (user, group, other), and then any extended ACL entries. Extended entries are labeled with 'user:' or 'group:' followed by the name and the permission set. For directories, getfacl also displays default ACLs if they are defined, which are used to set permissions for newly created files and subdirectories within that directory. Default ACLs are marked with 'default:user:', 'default:group:', etc. The permissions are shown in the traditional rwx format (read, write, execute) as well as in a symbolic mask string.

Technically, when a file with ACLs is accessed, the kernel checks the ACL entries in order. First, if the process user ID matches the file owner, the owner permissions apply. If not, the kernel checks if the process user ID matches any named user entry in the ACL. If yes, that entry's permissions apply. If not, it checks group entries: first the owning group, then any named group entries. The ACL mask is used to limit the permissions that can be granted by group entries and named user entries. The mask is automatically computed when ACLs are set, but it can be explicitly set via setfacl. If no match is found, the 'other' permissions apply. This evaluation order ensures that the most specific entry is used, providing fine-grained control.

The getfacl command supports several options. The '-R' option recursively lists ACLs for all files and directories under a given directory. '-d' displays the default ACL of a directory. '-c' omits the comment headers (like file owner and group) from the output, which is useful for scripting. '-p' omits the absolute path prefixes. The output can also be used as input for setfacl --restore, allowing backup and restore of ACLs. In many Linux distributions, getfacl is installed by default if the ACL package is included, but on minimal systems it may need to be installed separately.

In enterprise IT environments, ACLs are crucial for security compliance, such as HIPAA, GDPR, or SOX, where access to sensitive data must be logged and controlled. getfacl helps administrators audit permissions quickly. It is also used in debugging permission issues where a user unexpectedly can or cannot access a file. For example, if a user reports being unable to edit a file, running getfacl can reveal that although the user is in a group that has write permission, the ACL mask might be limiting that write access. The command is also used in scripts to generate permission reports for security audits. Understanding getfacl output is fundamental for Linux system administration and is tested in many certification exams, including Linux Professional Institute (LPI), Red Hat Certified Engineer (RHCE), CompTIA Linux+, and various other Linux-based exams.

## Real-life example

Think of a co-working space with different membership tiers and special guests. The basic rule is that anyone who is a member of the space can use the common areas, but only premium members can use the meeting rooms. That is like standard permissions: user, group, other. Now, the manager wants to let a specific non-premium member (let us call her Alice) use a meeting room for a one-time workshop, but without upgrading her entire membership. The manager puts Alice's name on a special list at the front desk that says 'Alice is allowed to enter meeting room B'. This list is like an ACL. Now, when Alice tries to enter the meeting room, the security guard (the kernel) checks the list. Alice is not a premium member, but her name is on the special list, so she is allowed in. The getfacl command is like asking the front desk to print that special list for you. It will show you that the meeting room has a base rule: 'premium members can enter', and then an additional rule: 'Alice can enter'. This is much more flexible than just having 'members' and 'non-members'.

Now imagine the co-working space also has a policy for new rooms that are added. The manager can set a default list that says 'any new room should automatically be accessible to all current premium members and also to Alice'. This default list is like a default ACL on a directory. When a new meeting room is created, it inherits those permissions automatically. getfacl on the parent directory would show this default list. So in real IT life, if you create a shared project folder, you can set default ACLs so that any new file created inside is automatically readable by the entire project team, but only writable by the team lead. This saves a lot of manual permission setting. The getfacl command is your go-to tool to verify that these rules are in place and working as intended. Without getfacl, you would have to guess or use complex scripting to figure out who has access, which is error-prone and time-consuming.

## Why it matters

In any multi-user operating system, especially Linux and Unix, managing permissions is a core responsibility of system administrators. Standard Unix permissions-owner, group, and other-are powerful but limited. They cannot handle situations where you need to grant different levels of access to multiple users and groups on the same file. For example, a company might have a confidential report that should be readable by the entire management team (20 people), writable by the finance director, and executable by an external auditor. Standard permissions simply cannot do that because they only allow one group entry. This is where ACLs (Access Control Lists) become essential, and getfacl is the tool to view them.

Without getfacl, administrators would have to rely on other methods like checking file owners, group memberships, and then guessing if ACLs are present. This is inefficient and prone to oversight. In security audits, you need definitive proof of who has what access. Getfacl provides that clear, machine-readable output. It also helps in troubleshooting: if a user cannot access a file, running getfacl might show that a specific ACL entry is blocking them, or that the mask is limiting permissions. It is also critical for scripting; many automation tools use getfacl to back up and restore permissions, ensuring that after a system migration or backup restoration, the same access controls are in place. In high-security environments, ACLs are used to enforce the principle of least privilege, and getfacl ensures that those policies are actually implemented. Therefore, understanding getfacl is not just about passing an exam; it is about being able to do your job effectively in real-world Linux administration. It is a skill that separates novice administrators from experienced ones.

## Why it matters in exams

The getfacl command is a specific but recurring topic in several Linux certification exams. For the CompTIA Linux+ (XK0-005) exam, objectives include managing file permissions and ownership, and ACLs are explicitly mentioned. Candidates are expected to know how to view ACLs using getfacl and set them using setfacl. Exam questions might present a scenario where a user cannot access a file, and the candidate must interpret the getfacl output to find the issue. For the Red Hat Certified System Administrator (RHCSA) exam, understanding ACLs is part of the 'Manage file permissions and ownership' objective. Red Hat exams often require you to configure ACLs to meet specific requirements, and you need to be able to verify your configuration with getfacl. The exam might ask you to ensure that a user has read access to a file without changing the group ownership or adding them to the group. The solution involves setting a user ACL, and then using getfacl to confirm it. For the Linux Professional Institute (LPI) LPIC-1 (101 and 102) exams, ACLs are covered in the 'File Permissions and Ownership' topic. The exam expects candidates to be able to use getfacl and setfacl to manage ACLs. Questions often ask about the output format, the effect of the mask, and how ACLs interact with standard permissions. For the SUSE Certified Administrator (SCA) exam, ACLs are also part of the objectives. In all these exams, the typical question type is either a direct command-line output interpretation (what does this getfacl output mean?), a scenario requiring you to choose the correct command to view ACLs, or a troubleshooting scenario where you need to identify why a permission is being denied. The key is to understand the output: recognizing the difference between user, group, mask, and other entries, and how the mask affects permissions. Candidates may be asked about default ACLs and how they propagate. Overall, getfacl is a relatively straightforward but important command that appears in multiple exams, and mastering it can earn easy points.

## How it appears in exam questions

Exam questions involving getfacl typically fall into three categories: output interpretation, command selection, and troubleshooting.

Output interpretation questions show the output of the getfacl command and ask what it means. For example, a question might display:

# file: report.txt
# owner: alice
# group: sales
user::rw-
user:bob:r--
group::r--
mask::rw-
other::---

The question might ask: 'Based on the ACL, which of the following is true?' The correct answer could be that user bob has read-only access, while the owner alice has read-write access. Another question might ask: 'What is the effective permission for a user who is in the sales group but not the owner or bob?' The answer would be 'r--' because the group entry is r--. Or they might ask about the mask: 'If the mask were r--, what would happen to bob's permissions?' The answer is that bob's permissions would be limited to r-- even if the ACL entry for bob says rw-.

Command selection questions are simpler. They might ask: 'Which command displays the ACL for a file named 'data.txt'?' The answer is getfacl data.txt. They might also ask about options: 'Which getfacl option recursively displays ACLs for all files in a directory?' The answer is -R.

Troubleshooting scenarios are more complex. For example: 'A user named 'jane' reports that she cannot write to a file /projects/tasklist. The file has the following permissions: owner is root, group is staff, others have read-only. Jane is a member of the 'staff' group. You check the ACL with getfacl and see: user:jane:rw- and mask::r--. Why can Jane not write to the file?' The correct answer is that the mask is r--, which limits the permissions granted by the named user entry (jane) and group entries to read-only, even though her ACL entry says rw-. The solution would be to change the mask to rw- using setfacl -m m::rw- /projects/tasklist.

Another troubleshooting scenario might involve a directory with a default ACL. For example: 'A directory /shared has a default ACL that gives user 'alice' read access. When alice creates a new file in that directory, she expects it to be readable by her, but it is not. Why?' The answer is that default ACLs only affect new files created 

*within* the directory, but they take effect only at creation time. If the file already exists and was created with different permissions, the default ACL does not apply. Also, the umask can interfere with default ACLs. So the candidate might need to check the umask and the file creation permissions. These scenarios test a deep understanding of how ACLs work in practice.

## Example scenario

You are the system administrator for a small marketing company. The company has a file called 'campaign_budget.xlsx' in the /finance/ directory. The owner of the file is 'sarah' (the finance manager), and the group is 'finance_team'. The standard permissions are that the owner can read and write, the group can read only, and others have no access. Sarah comes to you and says that 'mike', a member of the marketing team, needs to be able to read and write to this file for a joint project. Mike is not in the finance_team group. You cannot change the group to include Mike because that would give all finance team members write access, which you do not want. You also cannot change the owner. The solution is to use an ACL. You run the command 'setfacl -m u:mike:rw /finance/campaign_budget.xlsx' to grant Mike read and write access specifically. Later, you want to verify that it worked. You run 'getfacl /finance/campaign_budget.xlsx'. The output shows:

# file: campaign_budget.xlsx
# owner: sarah
# group: finance_team
user::rw-
user:mike:rw-
group::r--
mask::rw-
other::---

This confirms that Mike now has his own entry with read and write permissions. The mask is rw-, which allows those permissions to take effect. Now, if another user from HR named 'lisa' also needs read-only access, you can add another ACL entry: 'setfacl -m u:lisa:r /finance/campaign_budget.xlsx'. Running getfacl again will show user:lisa:r--. This shows how getfacl helps you verify the current state of permissions after changes. It is a simple yet powerful way to avoid mistakes and ensure that only the right people have access.

## Common mistakes

- **Mistake:** Thinking getfacl shows effective permissions directly without considering the mask.
  - Why it is wrong: The output shows the ACL entries, but the actual effective permissions for a named user or group are determined by the logical AND of the entry's permissions and the mask. For example, if a user has rw- but the mask is r--, the effective permission is r--. The command getfacl does not show the effective permission explicitly; you have to compute it.
  - Fix: Always check the mask value. The effective permission for any named user or group entry is the intersection of that entry's permission bits and the mask bits. The mask itself is shown in the output.
- **Mistake:** Confusing the 'other' entry with 'mask' in the output.
  - Why it is wrong: The 'other' entry applies to anyone not matching any user or group entry. The 'mask' limits the maximum permissions for named users, named groups, and the owning group (but not the owner). They are different concepts. The mask does not affect the owner or the 'other' entry.
  - Fix: Remember the order in the output: owner (user::), then named users, then owning group (group::), then named groups, then mask, then other. The mask is explicitly labeled 'mask::'.
- **Mistake:** Believing that getfacl modifies permissions.
  - Why it is wrong: getfacl is a read-only command that displays ACLs. It does not change anything. To modify ACLs, you must use setfacl.
  - Fix: Use 'getfacl' for viewing, 'setfacl' for modifying. If you need to copy ACLs from one file to another, you can use getfacl to output and then pipe to setfacl --set-file=-.
- **Mistake:** Assuming that default ACLs shown on a directory apply to existing files.
  - Why it is wrong: Default ACLs apply only to newly created files and subdirectories within that directory. They do not retroactively affect files that already exist.
  - Fix: If you want to apply an ACL to all existing files, you need to use setfacl with the -R option, or set ACLs on each file individually. Default ACLs are a convenience for future files.

## Exam trap

{"trap":"A question shows getfacl output with a mask value that is more restrictive than a named user entry, and asks what the user's effective permission is. The trap is that the candidate might directly state the named user entry's permission without considering the mask.","why_learners_choose_it":"Learners often see the user entry (e.g., user:bob:rw-) and assume that is the permission. They may not understand the role of the mask in limiting permissions for named users and groups. They may also confuse the mask with the 'other' entry.","how_to_avoid_it":"Always remember that the mask is a limiting factor for named users, named groups, and the owning group. The effective permission is the bitwise AND of the entry's permission and the mask. So if the mask is r--, then even if an entry says rw-, the effective is r--. Practice interpreting getfacl output with different mask values."}

## Commonly confused with

- **getfacl vs setfacl:** getfacl is used to view ACLs, while setfacl is used to set or modify ACLs. They are two sides of the same coin. You cannot change an ACL with getfacl, and you cannot view the current ACL with setfacl (though setfacl can output what it is setting). (Example: To see the ACL on file 'x', use 'getfacl x'. To give user bob read access, use 'setfacl -m u:bob:r x', then use 'getfacl x' to confirm.)
- **getfacl vs chmod:** chmod changes standard Unix permissions (owner, group, other) and the setuid/setgid/sticky bits. It does not manage ACLs. getfacl shows ACLs, which are an extension beyond standard permissions. A file can have both standard permissions and ACLs. getfacl will show standard permissions as the base entries (user::, group::, other::). (Example: If you run 'chmod 755 file', the file gets rwxr-xr-x. Running 'getfacl file' will show user::rwx, group::r-x, other::r-x. If you then add an ACL, getfacl will also show the extra entries.)
- **getfacl vs ls -l:** ls -l shows the standard permission string (e.g., -rw-r-----). This only shows the three groups: owner, group, other. It does not show any individual ACL entries. If a file has ACLs, ls -l will show a plus sign (+) at the end of the permission string (e.g., -rw-r-----+). The plus sign indicates that ACLs are present, but you need getfacl to see the details. (Example: If you see 'drwxr-x---+' in ls -l, the plus sign tells you that ACLs exist. Use 'getfacl .' to see the full list. Without getfacl, you do not know which users or groups have special permissions.)

## Step-by-step breakdown

1. **Install or verify ACL package** — On most Linux distributions, the ACL utilities are part of the 'acl' package. You can install it with your package manager (e.g., 'sudo apt install acl' on Debian/Ubuntu, 'sudo yum install acl' on RHEL/CentOS). Without the package, getfacl command will not be available. This step is important because some minimal installations omit it.
2. **Open terminal and run getfacl on a file** — The basic syntax is 'getfacl [options] file_or_directory'. For example, 'getfacl myfile.txt'. This will output the ACL information to the terminal. This is the most common usage. It is essential for verifying permissions.
3. **Interpret the first lines of output** — The output begins with the file name and the owner/group (e.g., '# file: myfile.txt', '# owner: root', '# group: staff'). These lines are comments (starting with #) and are informational. They indicate who owns the file and which group is associated. This is the same information you would get from 'ls -l'. Always check that you are looking at the correct file.
4. **Interpret the base ACL entries** — The next lines show the base entries: 'user::rw-' (owner permissions), 'group::r--' (owning group permissions), 'other::---' (others permissions). These correspond to the standard Unix permissions. The double colon (e.g., 'user::') indicates that no name is specified (it is the owner). These are always present even if no extended ACLs exist.
5. **Identify and interpret extended ACL entries** — Extended entries are shown as 'user:bob:r--' or 'group:sales:rw-'. These are the individual ACL entries for specific users or groups. The name (e.g., bob) appears after the colon. These entries give additional permissions beyond the base. Each entry has its own permission set. If there are no extended entries, the ACL is equivalent to standard permissions.
6. **Understand the mask entry** — The mask entry, shown as 'mask::rw-', limits the permissions that can be granted by named user, named group, and the owning group entries. The mask does not affect the owner or the 'other' entry. The effective permission for a named user is the bitwise AND of the named user's permission and the mask. For example, if the user entry is 'rw-' and the mask is 'r--', the effective is 'r--'. This is a common source of confusion.
7. **Check for default ACLs on directories** — If the target is a directory and default ACLs have been set, the output will include lines starting with 'default:' (e.g., 'default:user:bob:r--'). Default ACLs are applied to newly created files and subdirectories within that directory. They are important for ensuring consistent permissions on new content. Without them, new files might not inherit the desired access.
8. **Use options for recursive or other output** — The '-R' option recursively lists ACLs for all files and directories under a given directory. The '-d' option shows only the default ACL of a directory. The '-c' option drops the comment lines (owner/group), which is useful for scripting. The '-p' option omits absolute path prefixes. Knowing these options helps you get exactly the information you need, especially when writing scripts to back up ACLs.

## Practical mini-lesson

In a real-world IT environment, the getfacl command is indispensable for maintaining security and compliance. Let us walk through a typical scenario: you are an administrator for a university system. There is a shared directory '/projects/research' where multiple professors and their students need access. The directory is owned by professor 'dr_smith' and the group is 'faculty'. Standard permissions are set to rwx for owner, rwx for group, and --- for others. But now, a student named 'alice' needs write access to a specific file 'data.txt' within that directory. You cannot add alice to the 'faculty' group because that would give her access to all faculty files. So you use setfacl: 'setfacl -m u:alice:rw /projects/research/data.txt'. Then, you verify with getfacl. The output shows 'user:alice:rw-' successfully. But later, alice reports she cannot write. You run getfacl again and see that the mask is 'r--'. This is a silent limit: someone previously set the mask to r--, perhaps inadvertently. You fix it with 'setfacl -m m::rw- /projects/research/data.txt'. Now getfacl shows 'mask::rw-' and alice can write. This real example illustrates why getfacl is not just a command to run once; it is a diagnostic tool. You should run it whenever there is a permission issue.

Another practical use is in backup and recovery. Many administrators use getfacl with the -R option to dump ACLs for an entire directory tree into a file: 'getfacl -R /projects/research > acl_backup.txt'. Then, if a restore is needed, they can run 'setfacl --restore=acl_backup.txt' to reapply all the ACLs. This is much more efficient than manually setting permissions after a system migration. Professionals also use getfacl in automated monitoring scripts. For example, a script could run getfacl on critical files daily and compare the output to a known baseline. If any unexpected ACL entry appears, an alert is sent. This helps detect unauthorized permission changes. The command can also be used to generate reports for auditors: a sorted list of all files with ACLs can be produced, showing which users have elevated access. This is crucial for compliance with standards like PCI-DSS or HIPAA.

What can go wrong? The most common issue is forgetting that the mask exists. If you set a named user entry with read-write permissions but the mask is read-only, the user will not be able to write. This is a silent failure-there is no error message when you set the ACL. Only getfacl reveals the mask. Another issue is confusion between user entries: the owner entry (user::) is different from a named user entry (user:someuser:). If you accidentally set permissions for the owner using a named user entry, it might not work as expected because the owner entry takes precedence. Also, on some file systems like NFSv4, ACLs are implemented differently, and getfacl may behave differently. In NFSv4, ACLs use a different model with more granular permissions (like 'READ_DATA', 'WRITE_DATA', etc.) and the output format is different. So professionals need to know the file system type. Finally, many beginners forget that getfacl on a directory shows the ACL of the directory itself, not of its contents. To see the ACLs of all files inside, you must use the -R option. This is a common mistake in exam scenarios: a question asks 'what is the ACL of all files in /data?', and the candidate runs 'getfacl /data' without -R, only seeing the directory's ACL. The correct answer is to use 'getfacl -R /data'.

## Memory tip

Think of 'getfacl' as 'get face control', it shows you the face (the list) of who has permissions, just like a bouncer checking the guest list.

## FAQ

**Does getfacl modify the ACL of a file?**

No, getfacl is read-only. It only displays the ACL. To modify ACLs, you must use the setfacl command.

**Why does getfacl show a plus sign in ls -l but not the details?**

The plus sign in ls -l indicates that the file has extended ACL entries. To see the details of those entries, you must run getfacl.

**What does the mask entry in getfacl output mean?**

The mask limits the maximum permissions that can be granted by named user, named group, and the owning group entries. It does not affect the owner or other. The effective permission for a named user is the intersection of the user's entry and the mask.

**Can I use getfacl to see the ACLs of multiple files at once?**

Yes, you can specify multiple files on the command line: 'getfacl file1 file2 file3'. You can also use wildcards, like 'getfacl *.txt'.

**Does getfacl work on all file systems?**

getfacl works on file systems that support POSIX ACLs, such as ext2/3/4, XFS, Btrfs, and others. On file systems like FAT32 or exFAT, it will not work. On NFSv4, the ACL model is different and getfacl may have different output.

**Why does getfacl show an empty list for a file I just created?**

If a file has standard permissions without any extended ACL entries, getfacl will show only the base entries (owner, group, other). There will be no named user or group entries. This is expected behavior.

## Summary

The getfacl command is a fundamental tool for anyone managing Linux or Unix systems, especially when dealing with complex permission scenarios. It allows you to view Access Control Lists (ACLs), which are an extension of the standard Unix permission model that enables you to grant permissions to multiple specific users and groups on a per-file or per-directory basis. Understanding how to read the output of getfacl is critical: you need to recognize the owner, group, mask, and any named entries, and you must understand how the mask affects effective permissions. Without this knowledge, you cannot fully control access to your system's resources, and you may overlook security vulnerabilities or inadvertently block legitimate users.

For certification exams like CompTIA Linux+, RHCSA, and LPIC-1, getfacl appears in questions about permission management, troubleshooting, and configuration. Mastery of this command can earn you straightforward points, but only if you avoid common traps like ignoring the mask or confusing default ACLs with current ACLs. In real-world practice, getfacl is used daily to audit permissions, verify configurations, and back up ACLs. It is a small but powerful command that, when combined with setfacl, gives administrators fine-grained control over file access.

As you prepare for your exams, practice interpreting getfacl outputs with different mask values and multiple user entries. Write down scenarios where a user is denied access and use getfacl to find the cause. Integrate it into your study routine until it becomes second nature. In professional IT, this command will be a reliable companion for keeping your systems secure and compliant.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/getfacl