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.

  • 2
    I think the way it would "normally be resolved" is NFS. For SSHFS, perhaps you should ask your "expert" what they meant; I can't see how it's useful with a shared mount. I think you need to be more specific about what your previous issues have been and what use cases you have in mind. – Michael Homer Sep 24 '17 at 9:25
  • @MichaelHomer - tomorrow or as soon as possible I will add details about the previous issues with NFS But the fact is that we struggled with permissions under NFS for many years and could never find good solutions. I do not look forward to going back to NFS. I will look over notes and support cases to find the main problems we could not solve. – MountainX Sep 24 '17 at 9:28
  • How are you managing users and userids across the systems? Configuration management? Whatever happens on each system? – thrig Sep 25 '17 at 2:19
  • @thrig - there are only a handful of users. The user IDs are the same on each computer and it's static (not changing). The problem doesn't seem to be about configuration management, it seems to be how to give access to a group and enforce file permissions on the mounted directories. – MountainX Sep 25 '17 at 5:54
  • Did you consider using some version control system like git? – Basile Starynkevitch Sep 25 '17 at 12:41

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


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.

  • I'll clarify the question. We do NOT need real-time collaboration. (Also Git is not appropriate for our use case.) – MountainX Sep 24 '17 at 9:29
  • @MountainX What you say is that "[we] need to collaborate by reading and writing the files in a shared directory" and that "[the] documents are text files and spreadsheets". This calls for some form of software that allows for collaborative editing, or you will have severe issues with tracking who did what and making sure no two people are editing the same file concurrently. – Kusalananda Sep 24 '17 at 9:36
  • that is not our use case. Only 1 person is logged into the computer at the same time. We do not have a high requirement for change tracking, but when needed, we can use the revision tracking feature in Libre Office Writer, for example. – MountainX Sep 24 '17 at 9:39

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.