I have a directory with the following ACL rules setup:

cd /nobackupp13/jrwrigh7
getfacl .

I get

# file: .
# owner: jrwrigh7
# group: a1983

However, when I create testfile in this directory, the mask does not take on the default value and restricts the permissions of the file to just r-- instead of r-x:

cd /nobackupp13/jrwrigh7
touch testfile
getfacl testfile

I get

# file: testfile
# owner: jrwrigh7
# group: a1983
group::r-x                      #effective:r--
group:a1983:r-x                 #effective:r--

Supposedly umask should be overridden by ACL (see https://serverfault.com/q/349145/530204 ), but here are the results of umask anyways:

cd /nobackupp13/jrwrigh7

I get


Is there some other permissions system that is preventing this from working?

The end goal is to have every file created in this directory be r-x by the group a1983. The whole reason I'm going through this is that my research group have always run into issues accessing/running each other's files on compute machines we don't have admin control over. We are wanting to ensure that every script file is executable, regardless of whether the owner has set it as such.

  • What practical difficulties dose this cause? (update question to tell us) It is what I would expect (see my answer). However a directory should get x, as should an executable output by a compiler. Jul 2, 2020 at 16:40
  • @ctrl-alt-delor I've added the information to the question. tl;dr. I want all new files to have the execute privileges to the group Jul 2, 2020 at 17:42
  • You just repeated your self. This dose not tell me why you want the files to be executable. What benefit is there in having regular files be executable? Jul 2, 2020 at 19:16
  • 1
    @ctrl-alt-delor I've updated the question to give more detail as to why we want regular files to be executable. Jul 2, 2020 at 19:26
  • (Workaround) Note: execute is only a convenience with scripts. You can run them anyway, even if noexec is set on the file-system. Jul 2, 2020 at 19:55

2 Answers 2


general information

When a file is created by the open() syscall there is a mode setting. Each permission the file gets must be requested in this mode parameter.

If the parent directory does not have default ACLs then the permissions of the file are mode combined with umask.

If the parent directory does have default ACL then these and mode determine the owner permission and the permission for others.

All other ACL entries are taken unchanged from the default ACLs. In order to achieve the same effect the ACL mask is not computed from the ACL_USER, ACL_GROUP, entriesACL_GROUP (as it is when ACL are set explicitly) but it is set to the group part of mode.

The mask value is determined by both default ACLs and mode and the default mask. It contains only those permissions which are contained in all three elements. So usually the default mask is reduced but it can be used to reduce the other values, too.

The results can be confusing if programs act "strangely". E.g. gcc creates the output file with mode 666 and later executes chmod() with 777. But that only affects the permissions for the owner and others because the ACL entries have precedence.

your case

  • touch creates the file with mode 666.
  • The default ACL is set to 750
  • The result (permissions contained in both) is 640.
  • So if mask is computed to be the most restrictive combination of the permissions given on file creation and the ACL rules, then what does default:mask do? Because it appears to do nothing from this explanations (and others I've found). Jul 4, 2020 at 15:04
  • 1
    @JamesWright I made some more tests and added a paragraph about the (default) mask to my answer. Jul 4, 2020 at 15:30

If the file is not a directory or an executable (output by a compiler), then it will not have execute permissions.

Remember umask is a mask. It does not add permissions, it only blocks them. The program that creates the file will use a mode of rw, the mask will allow this on the owning user, and block the w on the groups, and block all on other.

  • Right, but ACL does add permissions, right? And it is the mask that is currently blocking the x permissions for the file. Jul 2, 2020 at 17:57
  • Does it? is it? Jul 2, 2020 at 19:17
  • I believe ACL adds permissions, but I'm not sure, hence why it's a question. And yes, the mask is the what is blocking execute permissions for the file. If I run setfacl -m m:rx testfile, the "effective" permissions are no longer there and the group will have the prescribed r-x permissions. Jul 2, 2020 at 19:28
  • At first I thought you are right. From the description in man 5 acl one would expect something different. I just did some tests. I will explain that in an answer. Jul 2, 2020 at 20:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .