0

I have a file owned by user1:group1. It has permission 770 deliberately so that other users in group1 can collaborate on it. When I open the file as user2 (who is in group1), I can edit it and save changes as expected, but when I save those changes the file ownership is changed to user2:user2.

The closest I found to the problem from my google search was this question prevent group ownership change on file save Which seemed to just say “put up with it”, but that was five years ago. Surely it can't still be the case that collaboration isn't possible within Linux desktop environments, so what am I doing wrong?

  • 1
    What editor are you editing with? What is probably happening is that the editor is replacing the file with a new version, rather than overwriting it. Since it is a new file, the user that saved it owns it. Some editors may be configurable to behave differently. – Kusalananda Aug 4 at 7:16
  • I makes no difference what editor I'm using (so far). I've tried the process in two different office applications, a photo editing application and a graphics program. The result is the same in all of them. – Isaacson Aug 4 at 7:21
2

If you set the "set group id" (SGID) bit on a directory, the files created in the directory inherit the group id of the directory, instead of the primary group id of the creating user. New subdirectories also get the SGID bit set automatically, so you don't need to do it manually; existing subdirectories must be changed manually, though.

  • Great, thanks - that's done the job. – Isaacson Aug 4 at 8:26
  • Consider also file-access-control-lists see unix.stackexchange.com/q/101263/4778 And revision control: Mercurial (easy to use), subversion (good if you need locking, because of un-mergable files), git (nice internal structure, and popular, but a git to use). – ctrl-alt-delor Aug 4 at 8:56
1

What is probably happening is that the program you are using for editing your file creates a new file when saving it, replacing the old file. A newly created file will always be owned by the user that created it.

To work around this (if the program has no obvious way of changing its behaviour), save the file with a new name, then run

cat newname >oldname

to replace the contents of the old file (oldname) with that of the new file (newname). It does this by truncating and rewriting the contents without creating a new file. Meta data, such as permissions and ownership, would not change. Then delete newname.


The other more obvious solution is to use something like git, or some other revision control system, for your collaborative work. This would allow each user to check out their own private copy of the files locally, work on these, and then check them into a central repository. Ownership and permissions on the files would no longer be an issue, and you'll gain the benefit of seeing who made what change when (and to roll back changes or fork development into separate branches).

A production checkout of the files could be done on the production system(s) while changes are made on the users' local machines. A new production copy would be checked out when testing shows that it works as expected (whatever it is you're doing).

  • Thanks for the answer, but I feel like I'm missing something and maybe didn't explain myself properly. It's just a simple shared file with group write access. It's not like a major collaboration on code or anything. What I suppose I'm asking for you to clarify is - what is group write access for without your workaround? I suppose I'm baffled that there isn't an easier way to collaborate on files with other users. – Isaacson Aug 4 at 8:01

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.