How to use ACL with SSHFS

Question

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.

Server:

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

Client:

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.

Update1:

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.

Update2:

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?

The group 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.

Footnotes:

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