So I am trying to understand the concept of groups and permissions in Linux, and am thoroughly confused. On my laptop, where I am the sole-user and thus super-user, I understand what it means to change file permission on text-files (chmod +x) to make it executable, or to change read-write permission (chmod +/- rw)

But I don't really get the concept of a group. From what I've gleaned a group is just a bunch of users. (But does that mean a user can belong to multiple groups?) A group as I understand is basically meant to make it easier to set/unset rwx permissions wholesale for a bunch of users (i.e. the group).

But now on this website the author says:

There are three levels of permissions in Linux: owner, group and other. The owner is the user who owns the file/folder, the group includes other users in the file’s group and other just represents all other users who are not the owner or in the group.

Does that mean that in addition to a file having an owner (i.e. the userid of the person who created the file) there is also a "group owner" for that file? And is this group typically one of the groups the file-owner belongs to?

What if I have three groups A,B,C on my system and want to set permissions rw-, -wx, r-x respectively on the system?

Asking the questions above very likely shows that my mental model of what a "group" and "group permission" in Unix is, is flawed.

I've tried reading up a bunch of articles but I seem to be missing something fundamental in understanding the notion of group and group permission. Can someone give me a succinct explanation or refer me to some clearer articles on this topic?

  • 11
    You're not the sole user, and you shouldn't be logging in as the superuser (root). Try cat /etc/passwd to see a list of users. Feb 24, 2020 at 16:38
  • I can't think of any situation in which -wx would be a useful permission flag.
    – skyler
    Feb 24, 2020 at 21:51
  • 1
    @skyler: the closest you can get to making "drop box" directory using just Unix permissions (if combined with +sticky bit)
    – user1686
    Feb 25, 2020 at 11:45
  • If you are unsure of the purpose of groups, just imagine breaking down the company you work for into groups like sales, manufacturing, HR, management, etc. Obviously, workers, like manufacturing, shouldn't look at sales or accountancy financial files; only management should get to update to other files (like employee reviews), etc, etc Some groups may be able to read, and others to update. E.g management can look at sales figures, but may not update them. Once you understand it in real world terms it should be easier to understand the excellent technical explanations which others give below. Feb 26, 2020 at 8:05
  • Run ls -l and inspect the 3rd column, that is the group. (Other answers are focusing on ACLs, so I thought I'd add in the basic version for clarity)
    – GammaGames
    Feb 26, 2020 at 18:38

3 Answers 3


But I don't really get the concept of a group. From what I've gleaned a group is just a bunch of users. (But does that mean a user can belong to multiple groups?)

Yes, and yes.

A group as I understand is basically meant to make it easier to set/unset rwx permissions wholesale for a bunch of users (i.e. the group).

One way it makes setting permissions much easier is when group needs access to many files or folders scattered around the system.

For example, whenever a new user joins, you would otherwise need to find all those files one by one and try to guess things like "if users A,B,C have access, then user D should be added". But if those permissions simply list a group name, then you don't need to update them at all – instead you just add the user to a group, done.

(It's not limited to just file permissions – some system services may also be configured to grant access to a group instead of individual users, with the same advantages as here.)

Does that mean that in addition to a file having an owner (i.e. the userid of the person who created the file) there is also a "group owner" for that file? And is this group typically one of the groups the file-owner belongs to?

Yes. Each user has a "primary group", and newly created files belong to that group. However, even non-root users can use chown/chgrp to reassign their own files to any group that they currently belong to.

(There's an exception: If the directory has the 'setgid' bit set, then newly created files in it inherit the directory's group, not the creator's. This is closer to how Windows NTFS works by default.)

Of course, this "group owner" system is a bit limiting when files can only have one group at a time. See the next section about that.

What if I have three groups A,B,C on my system and want to set permissions rw-, -wx, r-x respectively on the system?

Then you use another feature called "ACLs" (access control lists), which – as the name implies – allows you to specify an arbitrary list of users and groups to give access to.

Linux supports the POSIX ACL format, which is mostly a straightforward extension of the existing model. That is, if you first rewrite the existing permissions as:

user::rwx, group::r-x, other::---

now you can use setfacl or chacl to add your three additional groups as:

group:Family:rw-, group:Friends:-wx, group:Coworkers:r-x

Note to avoid confusion: POSIX ACLs try to remain compatible as much as possible with traditional chmod, but this leads to a surprising feature. As soon as you add ACLs to a file, the "group" field in ls -l will instead start showing something called a 'mask', and a command like chmod g-w will deny write access to all ACL entries, not just to the "owner group".

Why does Linux, or even Unix, use the 'owner/group/other' categorization if it could just use ACLs instead? It does because this simple categorization predates ACL support by decades.

Unix originally went for the simple approach, as most other operating systems did at the time – either due to disk space constraints (permission bits fit in just two bytes), and/or deliberate design decision (Multics may have had elaborate ACLs at the time, but plenty of things in Unix were intentionally simplified).

Eventually the APIs became set in stone – new ones could be added, but the existing "chmod" could not be changed, because programs already expected it to work in a certain way. (OpenVMS too had to keep its similar permission-bit system even after adding ACLs.)

In addition to that, unfortunately it's the only system cross-compatible between all of the Unix-like operating systems. Some other Unixes (e.g. FreeBSD, Solaris) may use a quite different ACL format, and yet others (OpenBSD) have no ACL support at all. Compare also to Windows, where all file protections are ACL-based.

  • 12
    I like to add: In addition to chgrp, there is also a sg (switch group) command, which change your active group (if you belong to multiple groups). sg starts a new shell, and as long as you work in this shell (until you type exit), any file created will belong to the other group. Feb 24, 2020 at 13:47
  • So user groups in UNIX are close to user roles in your typical relational database? And the group permissions associated with a file correspond to role grants on a db table?
    – iruvar
    Feb 25, 2020 at 18:40
  • 1
    @iruvar Basically yes. You can think of it like that if you're more familiar with the DB model.
    – Tonny
    Feb 26, 2020 at 12:22
  • If the user is in the groups Family and Friends are the permissions stacked? does the user have rwx in that case, or does it take one group? Feb 26, 2020 at 13:13
  • @Sven: In POSIX ACLs, group permissions stack with other group permissions – but they don't stack with 'user' or 'other'. See a description of the access check algorithm – I believe it's meant to closely imitate traditional Unix permissions, which are also exclusive (if you match "user" you won't match "group", and if you match "group" then you don't match "other"). Other ACL types work differently, e.g. Windows NTFS ACLs do stack.
    – user1686
    Feb 26, 2020 at 13:34

The concept of Linux/Unix groups can be confusing. But let's try to unpack that.

Files and directories have both an owner and a group (or a "group owner" as you put it.) They also have three sets of rwx permission bits, one for user, one for group and one for other. Additionally, they have three more bits of permissions: setuid, setgid and sticky. The user and group of a file or directory are internally stored as an UID and a GID, which are unsigned integer numbers that serve as internal identifiers for users and groups.

Users in the system have a UID and a GID (typically set in the /etc/passwd file), the GID setting from that file is used to indicate the primary group of an user. Additionally, an user may belong to more groups (typically configured in the /etc/group file, which lists additional users for each group in the system.)

You can check your user's UID, GID, primary group and additional groups with the id command, which will list all this information for the user running the command.

When you try to access a file or directory, the system will try to validate your access based on the permission bits. In particular, it will start by looking at whether to use the user, group or other bits. If your UID matches exactly the UID of the user accessing the file, then the "user" bits will be used. For the group, if either your primary group matches the group of the file, or if any of the additional groups (as reported by id) matches that group, then the "group" bits will be used. Otherwise, if none of those match, the "other" bits will be used.

Meaning of permissions for files are fairly straightforward, r means you can open the file for reading, w means you can open that file for writing (thus modify its contents) and x means you can run this file as an executable (whether it's a binary or a script.)

For directories, it's a little more subtle. r means you can list the files in that directory (for example, with ls /path/to/dir), w means you can create new files in that directory (or delete existing files from that directory.) But you need x to be able to access any of the files in that directory, if you don't have x on a directory, you can't cd to that directory and you can't really open files inside that directory, even if you know they exist. (This allows for quirky setups, where with r but without x, you can list the filenames but you can't open any of the files, while with x but without r you can open files in the directory only if you know their names already, since you can't list the filenames in the directory.)

Assuming you have permissions to create a new file in a directory, a new file that you create will have your user as the owner and by default it will have your primary group as its "group owner". But that's not always the case!

Remember I mentioned the setgid bit earlier on? Well, if a directory has the setgid bid set (you can set it with chmod g+s /path/to/dir), then new files created in that directory will inherit the group of the directory itself, rather than the primary group of the user that creates it. Furthermore, if you create a new subdirectory under such a setgid-enabled directory, the subdirectory will also have the setgid bit enabled. (That is necessary in order to preserve the group-inheritance property for the whole subtree.)

This setgid bit on directories technique is quite useful to implement shared directories. We'll get to that shortly.

One more note of interest is that the Unix systems in the BSD family (such as FreeBSD, NetBSD, OpenBSD) always behave as the setgid bit is set on a directory. In that way, the primary group of a user is somewhat less meaningful, since being the group during file creation is typically the most visible feature of this group.

Another concept of interest is the "umask", which is a set of bits that gets "masked" when a new file or directory is created. You can check your umask in the shell by using the umask command and you can also use that command with an argument to modify the current umask. Typical values are umask 002, umask 022, umask 027, etc.

The bits in the umask refer to the rwx bits and the three octal digits map to the user, group and other bits in a permission mode. So umask 002 will preserve all the bits for user and group (0 means no masking), while they'll block the w bit for other (2 is w.) They'll keep files user and group writable, but only readable by others. umask 027 on the other hand, will have writable only by the user, only readable/executable but not writable by group, and no access for other (7 means masking all of rwx.)

The umask is used every time a new file is created. Applications typically specify the permissions they would like, normally in the most liberal way, so that the umask can restrict that to more realistic permissions. For instance, normal applications will ask that files are created with 0666 (rw-rw-rw-) permissions, expecting the umask will drop at least the world-writable bit. Directories will be typically created with 0777 (rwxrwxrwx), assuming the same.

So how can we put this all together?

The setup typically used by Red Hat based Linux distributions (such as RHEL, CentOS and Fedora) is a pretty flexible one, worth looking into.

For each user that is created, a group of the same name is created too (typically with a GID matching the UID of the user) and that group is set as the primary group of that user. That group is meant to contain only the user by the same name. So files of my user are typically created as filbranden:filbranden, with my own primary group gating the group permission bits.

Since the group is essentially the same as just the user itself, the umask is set to 002, which means that all files and directories will be group-writable by default.

So how do you lock down directories to make them private? Simple, just remove the permission bits for "other" from the top level directory. For example, if I use chmod 770 ~ (or 700 is also fine, 770 works because the primary group is my own), no other user will be able to access any of the files under my home directory. That the files inside there have read or execute bits for "other" doesn't matter since by missing the x bit on the top directory itself means they'll never be able to traverse that one.

So how do you implement shared directories? Simple. Start by creating a group and adding all users who are meant to collaborate on that project to this group. Next, create one (or more) directories for that project. Set the "group owner" of the directories to the group you just created. Finally, enable the setgid bit on these directories. All the members of that group will be able to create files in those directories. Since they all have umask 002, the files they create will be group-writable. And because of the setgid bit in the top directory, all the files will be owned by the shared group (and not the per-user primary groups.) Which means users in the group will be able to modify files that were created by other members of the group, since they'll have write permissions to those files.

These shared directories can be world-readable (by keeping the r and x permissions for "other" in the top directory), or can be private to the group (by removing those permissions.)

That's the gist of it. How Unix/Linux permissions typically work and the rationale for why they work in this way.

There are, of course, many caveats. Many of these settings (such as the umask) exist in different sessions and it's possible they get out of sync. Adding a user to a group means they typically need to log in again for the change to have effect. While creating a file in a setgid-bit enabled directory causes the group of the directory to be inherited, moving an existing file into that directory doesn't typically change ownership (so you may end up with files in the group share that are not modifiable by other members of the group.) Semantics around deleting files can be somewhat tricky as well.

Modern Unix/Linux systems keep all the logic behind users, groups, file ownership. But they typically also include additional mechanisms to enforce permissions, such as extended file ACLs, which can be much more granular in allowing read/write access to directory trees and do not suffer from many of the issues with basic permissions listed above.

  • 1
    Good write-up!! It is a long book, but a good read for someone technical at least. Mar 23, 2020 at 23:51

Yes. Every file and directory has an owner and a group. If you type the command ll it gives you a list of files in the current directory with the owner and group listed.


If you do chown root:www <FILEPATH> you're setting the owner to root and the group to www.

If you do chmod 750 <FILEPATH> you're setting the owner permission to read/write/execute, the group permission to read/execute and the other (everyone) permission to none.

That means root will have full access and anyone in the www group can read/execute the file. So if you add the user 'sarah' and the user 'bill' to the www group then they will have read/execute permissions on the file as well.

What if I have three groups A,B,C on my system and want to set permissions rw-, -wx, r-x respectively on the system?

You don't set permissions on groups. You set permissions on each file/directory then assign each file/directory an owner and group. When you place a user in a group it gives them access to every file/directory that group has permission to access.

Let's say you have three files on the system with the 750 permission:

index.html (root:A)

index.txt (root:B)

index.php (root:C)

The owner (root) has full access (read/write/execute) to all of the files.
Anyone in group A can read/execute index.html (but not index.txt or index.php).
Anyone in group B can read/execute index.txt (but not index.html or index.php).
Anyone in group C can read/execute index.php (but not index.html or index.txt).

User 'sarah' can't access any of the files because she isn't the owner (root) or in any of the groups A, B or C. However, if you add the user 'sarah' to groups A and B then she would have read/execute permission on index.html and index.txt (but no permission on index.php). If you add the user 'bill' to groups B and C then he would have read/execute permission on index.txt and index.php (but no permission on index.html).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.