I've realized that the permissions for new files and directories behave a bit strangely. First of all, umask seems to return the right answer:

$ umask

This means full access for my user and my group, no write access for the rest of the world, no suid. But if I create a file in my $HOME, this is how it looks:

$ ls -l testfile 
-rw-rw-rw- 1 robe robe 0 mar 16 12:58 testfile

i.e. , giving write access to everyone. The same happens with directories:

$ ls -ld testdir
drwxrwxrwx 2 robe robe 6 mar 16 13:00 testdir

I think this is the same as having umask 0000, not 0002. I've searched all /etc for some instance of umask that changes the default 0002 or 0022, but found none. This is a default CentOS 5.5 install. Any hint of why is this happening?

  • 3
    What filesystem type is your home directory on?
    – mattdm
    Commented Mar 16, 2011 at 12:33
  • 4
    And how are you creating testfile and testdir?
    – mattdm
    Commented Mar 16, 2011 at 12:34
  • 3
    @mattdm, you were right to insist: it's XFS. I forgot we have separate volumes for /home, /var and several more. Though I use XFS often and hadn't seen this behaviour. How can it be related?
    – rsuarez
    Commented Mar 16, 2011 at 14:13
  • 2
    acl can override umask locally. Is it possible your directories are being mounted with acl? Commented Mar 17, 2011 at 21:33
  • 3
    Hmm, apparently xfs always has acl enabled. so it might not show in your /etc/fstab. Try running getfacl on your partitions/directories. Commented Mar 17, 2011 at 21:40

3 Answers 3


I don't know if it's proper to answer my own question. Editors, please, advise on this if this is not the case. Thanks in advance.

I think I've solved this mystery: the problem was the lack of a default ACL on the XFS volumes. Here's the ACL entry for /srv/backups, one of the directories affected:

# file: srv/backups
# owner: root
# group: root

Whenever I did a "mkdir test" or "touch testfile", it would came up with permissions 777. So I did this:

setfacl -m d:u::rwx /srv/backups

Leaving the ACL like this:

# file: srv/backups
# owner: root
# group: root

Previously there (supposedly) was no ACL, but now there is. I can see the "+" sign attached to the permissions when I do a "ls -l". And magically, now "mkdir test" and "touch testfile" work with the expected permissions:

# ls -l testfile 
-rw-r--r-- 1 root root 0 Dec 20 10:00 testfile
# ls -ld testdir
drwxr-xr-x+ 2 root root 6 Dec 20 10:00 testdir

I don't know why this happens. I guess XFS doesn't like not having a default ACL, and behaves strangely when it happens. Also, I've seen this happen only in CentOS, not in Debian/Ubuntu. Maybe it's related to the XFS version in the kernel, or something like that. No idea.

Anyway, that settles the case for me. Thanks a lot for all the suggestions :-)


The creat call can explictly specify permissions which take precedence over umask.

You haven't answered how you're creating testfile,testdir.

Create the file using touch testfile, then list and post the permissions

  • Sorry for the delay. I did test using "touch testfile", and also "mkdir testdir", with similar results. umask seems to be set to "0000", because they are created with permissions 777.
    – rsuarez
    Commented Dec 20, 2011 at 8:43

Just look for the USERGROUPS_ENAB variable on /etc/login.defs

Them comment in order to disable it # USERGROUPS_ENAB yes

If you also want to change your current user's umask, you should first fallow the previous procedure and them do the following.

example for 027

echo "umask 027" >> ~/.bashrc && pkill -KILL -u your_username_here

echo "umask 027" >> ~/.bashrc this command will set an umask default value for your profile

this will force you to log out

after login again

just run the umask comand again and see if it works for you

You must log in to answer this question.

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