I want to allow users in the same group ("team") to edit the same files on the server. The directory containing these files is mounted via SSHFS.
So far, I was not able to accomplish my goal using umask setting*. Now I will try ACL's. I set the following default ACL's on the directory on the server, then I mounted it on the client.
setfacl -d -m g::rwx . [root@sshfsrv]# getfacl . # file: . # owner: user3 # group: team # flags: -s- user::rwx group::rwx other::r-x default:user::rwx default:group::rwx default:other::r-x
The directory is mounted on the client with
sshfs -o allow_other,default_permissions (and the allow_other option is enabled).
The default ACL's are not present on the client and files do not have rw permissions for group, preventing users in this group from working on the same files.
[user3@client2]# getfacl . # file: . # owner: user3 # group: team # flags: -s- user::rwx group::rwx other::r-x
I have restarted sshd and I have logged out and back in on the client. Trying to run the
setfacl command on the client fails with "Operation not supported".
Why are the default ACL's not present on the client?
Is there another method by which I can accomplish my goal of allowing all users who are members of the "team" group and who have logins on the client PC to collaborate on (r/w) the same set of remote files using a local mount point.
Both client and server are running OpenSSH_7.5p1, OpenSSL 1.1.0f dated 25 May 2017. Both run Arch Linux.
On the server,
systemctl status sshd shows Main PID: 4853 (sshd)
# cat /proc/4853/status Name: sshd Umask: 0022 State: S (sleeping) Tgid: 4853 Ngid: 0 Pid: 4853 PPid: 1 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 64 Groups: NStgid: 4853 NSpid: 4853 NSpgid: 4853 NSsid: 4853 VmPeak: 47028 kB VmSize: 47028 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 5644 kB VmRSS: 5644 kB RssAnon: 692 kB RssFile: 4952 kB RssShmem: 0 kB VmData: 752 kB VmStk: 132 kB VmExe: 744 kB VmLib: 6260 kB VmPTE: 120 kB VmPMD: 16 kB VmSwap: 0 kB HugetlbPages: 0 kB Threads: 1 SigQ: 0/62965 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000001000 SigCgt: 0000000180014005 CapInh: 0000000000000000 CapPrm: 0000003fffffffff CapEff: 0000003fffffffff CapBnd: 0000003fffffffff CapAmb: 0000000000000000 Seccomp: 0 Cpus_allowed: 3f Cpus_allowed_list: 0-5 Mems_allowed: 00000000,00000001 Mems_allowed_list: 0 voluntary_ctxt_switches: 25 nonvoluntary_ctxt_switches: 2
In /etc/ssh/sshd_config we have this Match clause:
Match Group team ForceCommand internal-sftp -u 0006
I can provide more info upon request.
I want to allow users in the "team" group to edit (rw) the same files on the remote server (via local mounts).
that statement needs a lot more details
See details below.
What user does the SSHFS mount?
team contains 3 users: user1, user2, user3. Any one of them can do the SSHFS mount. But the problem always becomes permissions / access for the other two users. So my question really concerns the others users in the group other than the one named in the mount command. I have tried variations on the mount command, but it currently looks like this:
user3@sshfsrv:/home/common /home/common fuse.sshfs x-systemd.automount,_netdev,user,follow_symlinks,identityfile=/home/user3/.ssh/id_rsa,allow_other,default_permissions 0 0
Are local users mapped to users in the same group on the remote server?
The users and groups have the same IDs. No mapping is required.
SSHFS is a bad idea in general (subject to TCP meltdown), and particularly so when multiple users are using it.
I have not heard this before. Many smart people recommend SSHFS. But if we can't make it work, we'll have no choice but to switch to something else...
Have you considered something like NFS over IPSec?
We used NFS for ten years and it was never very satisfactory in terms of permissions. Some "expert" recommended we switch to SSHFS, which we just did. He said it would solve our permissions issues. So far, the switch is not going well, as you see from the question, but I am hopeful that with some knowledge we'll resolve these issues. Not ready to give up on SSHFS just yet, but it is always possible we'll have to go back to NFS, although it really wasn't very satisfactory in terms of managing user permissions / access.
Or perhaps just use Git instead of allowing people to edit files directly.
Git is not a solution for this situation.
* umask settings, while working fine in my command line testing, did not work for desktop users. We found the file manager failing to move files and crashing and several user applications trying to save files with the wrong permissions and/or failing to be able to save files at all. It was a disaster.