Home / server / Questions / 280964
In Process
gAMBOOKa
Asked: 2011-06-16 23:34:33 +0800 CST

Maintain ownership in a directory regardless of who adds / edits files within it

  • 772

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?

linux redhat permissions file-permissions

3 Answers

  1. 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.
    • 4

  2. 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.

    • 1

  3. 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.

    • 0