I am using the following steps to set permissions and default acl permissions.

chown as required
find . -type d -exec chmod 770 {} \;
find . -type f -exec chmod 660 {} \;
find . -type d -exec chmod g+s {} \;
setfacl -Rdm g::rw .
setfacl -Rdm u::rw .
setfacl -Rdm o::- .

This produces the desired results except that newly created sub-directories cannot be entered (by owner or group) because they have 660 permissions instead of 770. How can I correct this one issue without changing the default permissions for new files?

Currently we have to do this after creating a new sub-directory:

chmod ug+x <sub-directory>

I want to eliminate that manual step because my users often don't know how to do it. I want them to be able to create a directory in the file manager and have immediate access to it.

UPDATE: The umask for all users is set as follows:

cat /etc/profile
# /etc/profile
umask 006
  • 1
    see man setfacl and the X permission (note that is a capital "X").
    – phemmer
    May 23, 2018 at 23:47
  • @Patrick - is the uppercase X used with default acl permissions? The man page leaves me with questions. Maybe you could give an example specific to my question? Thanks
    – MountainX
    May 23, 2018 at 23:53
  • @Christopher - my understanding is that for lowercase x permissions to work correctly, the umask must be set correctly. (Also users can set their own umask.) Instead, I'm trying the capital "X" permission now, based on the responses here. I'll see if that meets our needs over time.
    – MountainX
    May 24, 2018 at 1:44

1 Answer 1


You're setting default ACLs that don't have the execute permission at all, so nobody will have execute permission. Instead, as Patrick mentioned in a comment, set default ACLs with the X permission. Lowercase x means that the ACL entry grants the execution permission. Uppercase X grants the execute permission only if some user (usually the owner) has the execute permission.

Unless you're doing something unusual, always put X in a default ACL wherever there's an r. There are few reasons to have a file or directory that's readable but not executable or vice versa. Unix implements execution and reading as separate permissions, and for directories it implements traversal and listing as separate permissions, but there are very few cases were this is desirable: usually a certain set of users is allowed to modify a file, a larger set is allowed to access it without modifying it, and for regular files the file may or may not be executable but that property doesn't depend on who is trying to access it.

setfacl -Rdm g::rwX .
setfacl -Rdm u::rwX .
setfacl -Rdm o::- .

You must log in to answer this question.

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