Super User is a question and answer site for computer enthusiasts and power users. 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 have a directory called data. Then I am running a script under the user id 'robot'. robot writes to the data directory and update files inside. The idea is data is open for both me and robot to update.

So I setup the permission and owner group like this

drwxrwxr-x  2 me robot-grp 4096 Jun 11 20:50 data

where both me and robot belongs to the 'robot-grp'. I change the permission and the owner group recursively like the parent directory.

I regularly upload new files into the data directory using rsync. Unfortunately, new files uploaded does not inherit the parent directory's permission as I hope. Instead it looks like this

-rw-r--r-- 1 me users       6 Jun 11 20:50 new-file.txt

When robot tries to update new-file.txt, it fails due to lack of file permission.

I'm not sure if setting umask helps. In anycase the new files does not really follow it.

$ umask -S

I'm often confounded by Unix file permission. Do I even have a right plan? I'm using Debian lenny.

share|improve this question

migrated from Jun 13 '10 at 1:45

This question came from our site for professional and enthusiast programmers.

You do not want to change your system's default umask, that is a security risk. The sticky bit option will work to some extent, but using ACL's is the best way to go. This is easier than you think. The problem with basic ACL's is that they are not recursive by default. If you set an ACL on a directory, only the files inside that directory inherit the ACL. If you create a subdirectory, it does not get the parent ACL unless the ACL is set to recurse.

First, make sure ACLs are enabled for the volume the directory is on. If you have tune2fs, you can perform the following:

# tune2fs -l /dev/sda1 | grep acl
Default mount options:    user_xattr acl

If you don't have tune2fs, then examine fstabs:

# cat /etc/fstab 
/dev/system/root        /                       ext3    defaults        1 1
/dev/system/home        /home                   ext3    defaults        1 2
/dev/storage/data       /data                   ext3    defaults        1 2
LABEL=/boot             /boot                   ext3    defaults        1 2

The 4th column that says "defaults" means on my system (CentOS 5.5), ACL's are on. When in doubt, leave it as defaults. If you try to set the ACL and it errors out, go back and add the acl option to /etc/fstab right after defaults: defaults,acl.

From what I understand, you want everyone in the users group to have write access to the data directory. That's accomplished by the following:

setfacl -Rm g:users:rwX,d:g:users:rwX data/
share|improve this answer
Great! It worked for me on Ubuntu. – armandomiani Jan 26 '12 at 5:32
I used this command but it didn't fix my problem, how can i undo this command please? – Itai Ganot Aug 15 '13 at 9:37
Did the trick on ubuntu with sudo setfacl -Rm g:users:rwX,d:g:users:rwX /var/www/logs_or_something. Had problem with PHPUnit tests. After creating log files from running tests apache user www-data couldn't write/read them. – s3m3n Aug 26 '13 at 10:12
@Itai Ganot - according to the setfacl man page, -b or --remove-all removes the extended ACLs. – jww Apr 3 '14 at 0:09
Thanks a lot @noloader – Itai Ganot Apr 5 '14 at 12:40

Marking a directory setgid (g+s) will make new files inherit the group ownership of the directory, but the -g option of rsync will attempt to override this.

share|improve this answer
The setgid bit only makes created files inherit the group /if/ the person creating the new file is a member of that group; if the creating user is the owner but not a member of the group, or the directory is world-writable, the setgid bit won't do anything. And the umask for all file-creating users still needs to be set to allow appropriate group access. – dannysauer Sep 12 '13 at 18:18

Your umask is wrong for the permissions you want. You want a umask of 002. You currently have a umask of 022. Also, the comment about making the directory setgid is correct, but I'm not sure if the file group ownership is something you want to change or not.

Unix file permissions are actually a very simple model. I find ACLs completely confusing myself. :-)

share|improve this answer
"Unix file permissions are actually a very simple model. I find ACLs completely confusing myself." - I kind of feel the opposite (but +1 anyways). ACLs (and Allow/Deny ACEs) are simple, and Unix permissions make no sense. But that's coming from a guy who is suffering a Postfix/Dovecot/Clam/SpamAssassin install. – jww Apr 2 '14 at 23:55

Other answers apply in a general case, but as you mention that rsync is a source of the problem, you may just need to tune its invocation.

For a start, the popular -a flag makes rsync copy permissions; use -r istead of -a or add -no-p (for no permission sync) and -no-g (for no group sync). Also rsync supports --chmod flag to alter permissions on newly created files.

share|improve this answer

You must log in to answer this question.

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