How to let users collaborate by editing files in a shared directory

Question

I have what I think is a very normal, very typical use case. I am surprised it seems (so far) that there is not a solution. I assume I am overlooking something obvious. Many people must need a solution for this use case.

Up to five different users in the same group have login accounts on one computer. They do not all log in at the same time.

Update 1: The documents are text files and spreadsheets that reside on our local server. We don't want to host documents on Google or any outside server.

We do not need real-time collaboration.

These users in the group "team" need to collaborate by reading and writing the files in a shared directory. The directory containing these files resides on a local server. The shared directory can be mounted on the client by standard Linux methods. We could use ACLs if needed because BTRFS has built-in support.

All users can log into the server via SSH using keys. The user and group ID's are the same on client and server. None of the users have sudo permissions or any other special permissions. All they have in common is membership in group "team".

The shared directory is not under any user's home directory. It is owned by the same group "team" with rwx permissions and it's path is fully accessible to all the users in "team". We can change permissions as required, but no users outside of "team" group shall be able to read or write files in this directory.

The client and server both run Arch Linux and both also run BTRFS.

We tried NFS for around ten years and we had many permissions / access problems. One of our top support issues was resolving permission problems for users. We decided to switch away from NFS because we never found a good solution for the permissions problems.

We switched to SSHFS because "we could just use normal file system permissions". So far we have not been able to achieve our simple goal stated above with SSHFS. See here and here.

We don't hear a lot of good things about Samba, so we never tried it. What else is there?

This seems to be such a common use case. How would it normally be resolved?

We don't even have a complex case. For example, all machines (servers and clients) in our network run Linux. And all machines are on a local LAN. It's simple. But I have not found a solution that will work.

Answer 1

It's actually fairly easy. Most people seem to think that they need to set permissions of all files under a given directory, but this is not true. Just the toplevel directory will do:

chown :team /path/to/dir
chmod 2770 /path/to/dir

First we set the group owner to the team group, which you say already exists and contains the people who should be able to access the correct directory. Next, we set the permissions to "set group id" on the directory (so any files created below that directory will be owned by the team group, too; not strictly necessary, but I find it to be a useful reminder), and give full permissions to anyone in the team group as well as the directory owner. Anyone not in that group will have others permission, which is empty here.

The result of this setup will be that for anyone not in the team group, even doing an ls on that directory will get Permission denied. People who are a member of the correct group, however, will be able to read and write in that directory, provided no files are individually set to file permissions which are wrong. If no such files should be protected against writing, correct the permissions now:

chmod -R g+rw /path/to/dir
find /path/to/dir -type d -print0 | xargs -0 chmod g+x

In the absense of ACLs, setting the permissions for future (i.e., newly-created) files is not something you can do by creatively setting permission bits; users need to set their umask. You can do this by way of a line in /etc/profile:

umask 002

It's important to set that, because the default on many distributions will be 022 (allowing read, but not write, permissions to group members), 077 (allowing nothing to other users), or 027 (allowing read, but not write, to group; and nothing to others). Neither of those options are what you want.

If you have different requirements for different parts of your filesystem, or you want to ensure that people don't mess things up by fiddling with their umask individually, you can use default ACLs instead:

find /path/to/dir -type d -print0 | xargs -0 setfacl -m d:g:team:rwx -m d:o:---

Once you've set it all up, it really does not matter whether you use SSHFS or NFS. If it still does not work, however, it's probably best to come back with more specific questions

Answer 2

Depending on what the document is, either use a proper version control system like git with a repository that is accessible by all (good for collaborating on software), or use something like Google Docs that allow for collaborative editing of text files (good for collaborating on e.g. reports). These are the solutions in use at my current workplace.

See also the Wikipedia entry on Collaborative real-time editor.

IMHO, concurrent editing of documents on a shared drive is problematic as documents saved by one user would easily overwrite changes made by another user. There is also no way of tracking who made what changes or roll back changes to earlier versions of the document.