Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
What filesystem type is your home directory on? – mattdm Mar 16 '11 at 12:33
And how are you creating testfile and testdir? – mattdm Mar 16 '11 at 12:34
@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 Mar 16 '11 at 14:13
acl can override umask locally. Is it possible your directories are being mounted with acl? – Faheem Mitha Mar 17 '11 at 21:33
Hmm, apparently xfs always has acl enabled. so it might not show in your /etc/fstab. Try running getfacl on your partitions/directories. – Faheem Mitha Mar 17 '11 at 21:40
up vote 3 down vote accepted

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 :-)

share|improve this answer
Answering your own question is perfectly acceptable. – Keith Thompson Dec 20 '11 at 10:30

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

share|improve this answer
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 Dec 20 '11 at 8:43

Try a getfacl . in the directory you are creating your test file, to see if there is a default acl affecting the permissions.

share|improve this answer
Nope, no default ACL. It seems to be related to XFS somehow, because it only happens in XFS volumes. But thanks anyway. – rsuarez Dec 20 '11 at 8:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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