757 allows read, write, execute by owner + read, execute by owner group + read, write, execute by others.

Is there any way arround to specificaly allow read only to user01? Please exclude the solution with bind mounting, because this directory holds a huge amount of small files. Bind mounting causes 0% free inodes error in a few days.



You are looking for Access Control Lists (ACL), which offer much more granular access controls than the traditional user/group/other permissions.

The file-system needs to be (re-) mounted with the acl mount option to enable ACL's. To enable ACL's on the /data volume:

mount -o remount,acl /data

and/or edit /etc/fstab to make the change persistent.

Then the setfacl command allows you to change ACL's and getfacl will retrieve them.

For example, to give read permissions to user bob:

setfacl -m u:bob:r Data
getfacl Data

# file: Data/ 
# owner: herman 
# group: staff 

A visual indication that ACL's are present is a + in the 11th permission column in GNU ls -l extended output:

drwx------+   39 herman  staff     1326 Nov 23 09:58 Data
          |_ + to indicate ACL's (or . to indicate SELinux context) 

Check for instance this manual for some more user friendly explanation than the man pages.


The "proper" way to achieve this would be ACLs, which means following the answer provided by HBruijn.

However, that is not to say it is impossible to solve this using traditional Unix file permissions. Without using ACLs, the same goal can be achieved as follows:

  • Make the file owned by a group read-only-users.
  • Place the user(s) who should have read-only access into the read-only-users group.
  • Set permissions of the file to 757.

Why does this work?

Unix file permissions are not evaluated so that the most permissive wins, but according to the file's class. This means user(s) in a particular file class have distinct permission sets:

  • Owner file class - if the owner performs an action, his/her operation is evaluated against the owner permission mode bits (first digit in the bitmask).

  • Group file class - if a user is not the file owner, but is otherwise a member of the file's group, the effective permissions governing that operation are the group permission mode bits (second digit in the bitmask).

  • Other file class - if a user is neither the file owner, nor a member of the file's group, the other permission mode bits apply (third digit in the bitmask).

In this instance, we give the file a distinct group to which we add read-only users. When permissions are evaluated, members of that group are restricted to the group permission bitmask, which expressly prohibits writing to the file. This achieves the stated objective.

Caveat - file owner

For obvious reasons, you cannot lock down the file owner using this technique. The permissions assigned to the owner will always take precedence over group permissions, even if the owner is a member of read-only-users. In any case, even if you do restrict the owner, on a standard Unix system, they will always have the ability to call chmod(1) to give themselves permission, irrespective of what their current bitmask is.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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