An odd situation came up recently. User1 needed to be able to change files in a directory were the files and the directory were owned by User2 and in group User2. In order to facilitate this editing, the permissions were changed to 757 recursively for the directory structure. Thus a listing looked something like the following.

drwxr-xrwx 3 user2 user2 4096 Nov 19 19:41 .
drwxr-xr-x 3 user2 user2 4096 Nov 19 19:41 ..
drwxr-xrwx 3 user2 user2 4096 Nov 19 19:41 directory1
drwxr-xrwx 3 user2 user2 4096 Nov 19 19:41 directory2
drwxr-xrwx 3 user2 user2 4096 Nov 19 19:41 directory3
-rwxr-xrwx 3 user2 user2   42 Nov 19 19:41 file1

User1 was able to read the files however attempts to create new files or edit/copy over existing files failed. The error was something like the following.

$ touch file1
touch: cannot touch 'file1': Permission denied

Thinking that maybe the drive was write protected somehow, User1 asked User2 to change the file. User2 was able to do so without any issues thus indicating the drive was not write protected.

Looking at df and /etc/fstab, the file appeared to be on a locally mounted hard drive.

Other info. User1 is in group User2. (This was originally thought not to be the case) There were no locks on the file. It appeared as though SE Linux was disabled. (As indicated by sestatus) While I recognize normally you would not want to set an entire directory to allow anyone to write to it, this is a special case. Almost an identical build on a separate machine worked. The output of getfacl is the same for the files and directories.

# file: .
# owner: user
# group: user

What can cause this protection and how can it be undone?

  • 1
    Please, list the groups of user user1. Is she in group user2?
    – andcoz
    Commented Nov 20, 2014 at 1:20
  • 2
    Can you provide getfacl output on the directory & the file ? Commented Nov 20, 2014 at 1:20
  • @ Rianto Wahyudi, Can't do getfacl now but I will when I can. getfacl is new to me but after looking at its description in the man pages that may point me in the right direction.
    – R Schultz
    Commented Nov 20, 2014 at 1:22
  • @Rianto Wahyudi. The Access Control List seemed promising but there doesn't appear to be anything special about them. While I have learned that you could block access to a specific user or group of users, this does not appear to be the source of my problem.
    – R Schultz
    Commented Nov 20, 2014 at 22:42
  • @andcoz - After trying to figure out what might cause this, I verified that what I assumed about the groups was correct. It wasn't. Just goes to show you that what they say about assuming things is true. With that, the answer follows.
    – R Schultz
    Commented Nov 22, 2014 at 1:32

1 Answer 1


I was going to simply delete the question since one of the original facts was incorrect. I decided that since the obvious answer was missed and there is an alternative not so obvious answer to post the possible causes and solutions to this problem aid those that may run into a similar issue in the future.

1) If you have this problem and you think that user1 is not part of user2, personally verify this by having user1 check there groups or examining the passwd file. In this case, the user1 was mistakenly added with the following /etc/passwd entry and no entry in /etc/group.


while user 2 had the following in /etc/passwd



user2:x:1000:user2 user1

Group permissions take priority over Other permissions, thus writing was not allowed. This could be fixed by changing the group permissions or removing user1 from the user2 group. This was the easy answer that had the initial assumptions been correct, many people probably would have gotten. Note to self, when something doesn't work, verify for yourself.

2) The less obvious answer comes from using file Access Control Lists (ACLs). If the user in question has specific permissions assigned, they take priority over the general permissions. While this may be known by those who have used ACLs, I suspect many don't even know they exist. Here is an example of how to this can block a user.

$ sudo setfacl -m u:user:r-x .
$ ls -la
total 0
drwxr-xrwx+  2 root root  60 Nov 21 20:46 .
drwxrwxrwt. 12 root root 300 Nov 21 20:45 ..
-rw-rw-r--.  1 user user   0 Nov 21 20:46 dog
$ touch cat
touch: cannot touch ‘cat’: Permission denied
$ getfacl .
# file: .
# owner: root
# group: root

To undo this

$ sudo setfacl -b .
$ sudo getfacl .
# file: .
# owner: root
# group: root

$ touch cat
$ ls -la cat
-rw-rw-r--. 1 user user 0 Nov 21 20:51 cat

Thank you @andcoz for asking about the groups which ultimately made me go back and re-verify and thank you @Rianto Wahyudi for mentioning 'getacl' which I had not seen/used before.

You must log in to answer this question.

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