Server Fault is a question and answer site for system and network administrators. 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

We have a development directory shared by our team. Everytime a user adds a file, the ownership changes to that user. Is there a way to ensure that the owner of files added within a directory always remains the same?

share|improve this question
not on linux no as it ignores the setuid bit on directories, however freebsd can do this. linux will do setgid just fine though. – Sirex Jun 16 '11 at 8:46
Is this a situation where you could introduce a version control mechanism -- like git or subversion -- such that everyone would work on their own copy of the material, and the "shared" directory would simply be a working copy maintained via automatic checkouts? We use this model for a variety of situations and it works out great. – larsks Jun 16 '11 at 13:23
@larsks: that's exactly what we're doing, how do you make it work? I'e all the users added to a certain group, but when one user commits a new file, another user loses access because the file belongs to another user now. – gAMBOOKa Jun 16 '11 at 13:39
Given this new information I've added what I hope is a helpful answer. – larsks Jun 16 '11 at 13:49

If you're accessing the directory via SMB using Samba, you can use the force user parameter in smb.conf. Otherwise, you really can't force the owner. However, if the problem is merely that the users can't edit each other's files in the directory, you can fix it by doing this:

  1. Get everybody to use umask 002 (or 007). Check /etc/profile and /etc/login.defs. This will ensure that files are group-writable.
  2. Make the directory (and all subdirectories) owned by a specific group that every team member is a member of.
  3. Make the directory (and all subdirectories) setuid group ("chmod g+s"). This is a special feature in Unix which will make all new files owned by the common group.
share|improve this answer
#3 is the correct answer. – Apreche Jun 16 '11 at 11:56
@Apreche: No, doing 1, 2 and 3 in that order is the correct answer. – Teddy Jun 16 '11 at 13:04

No, but you can make the directory setgid so that the group owner of the directory has group ownership of any files created within it.

share|improve this answer

The standard solution for this problem -- sharing a version control repository among multiple users -- is to have everyone interact with the repository via a server running as a dedicated user rather than via the filesystem. As you've discovered, using the filesystem is problematic.

You haven't specified which version control system you're using, but with either Suversion or git you would set up a dedicated user on your system, and then have your developers access the repository over ssh. With Subversion you would use svn+ssh urls; there's some documentation in the svn handbook.

The default behavior for git is to use ssh to access "remote" repositories. I put "remote" in quotes because in your case you'll be running the "server" on the local system.

share|improve this answer

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.