As I promised to @gerald_FS I started to look after NFS and the shared folder, don’t hold your breath it is really the beginning of the search. However it is time to hear your needs and how you want it.
Firstly I found that the linux acl is working well even with nfsV3, but the drawback is that the acl GID or acl UID must be clear and set recursively to the shared folder.
I know I haven’t posted since December but I’m still interesting in this, just focused on other things.
I’m not quite sure what you meant by this. The setfacl stuff looks good, that’s exactly what I had in mind. For mapping, NFSv4 has idmapd, which is trivial to set up. See my earlier post.
Thinking a bit about it, I can see different authorization mechanism between Samba and NFS protocols: Samba access is user based, while NFS is IP based.
I suggest to move to a simpler scenario: when NFS access is enabled on a shared folder, Samba access is possible only as guest. In this case you shouldn’t care about ACLs.
It is one way probably less risky to break something, but I’m not sure that it is what our end-users are waiting for.
I will try the @Chewi way and report it, my first attempt works (with nfs3, not tested with nfs4), you don’t really need to allow the IP, just the network range and the ‘RW’ are needed, after all is managed by the Ibay acl that you must adapt following the clients who want to access. (see my first post)
Of course when you play with ACL, then I suppose that the same GID/UID will be allowed also in Samba
I would really stick with NFSv4. I’m not sure that v3 has all the features we need and I find v4 performs much better. I don’t know why people still bother with v3 on servers, v4 is backwards compatible with v3 clients.
As a first step, I agree with Giacomo: I’d go with IP based access. This simple authorization method works great with backup solutions!
User-level access requires authentication, and AFAIK NFS uses kerberos. Now, our Kerberos DC is Active Directory. But with AD we already have SMB as file access protocol.
So I wouldn’t consider NFS user-level access a priority, unless we start to develop the support to another Kerberos-capable account provider (FreeIPA?) …but I might be wrong!
@Chewi thanks for answering my call and for your comment on phoronix. Didn’t know you’re a senior member over there.
Talking about NFS which scenarios are we covering here? That aren’t already achieved by CIFS?
I don’t think this is so much about what NFS can do that CIFS can’t. Some people just don’t want to use CIFS and my colleague said it’s dog slow on a remote connection. Not that we’ve tried NFS remotely but I suspect it will be better.
[lsd@leo ~]$ sudo mount -t nfs4 -o sec=krb5p 192.168.12.172:/var/lib/nethserver/ibay/plop toto/
[sudo] Mot de passe de lsd :
mount.nfs4: access denied by server while mounting 192.168.12.172:/var/lib/nethserver/ibay/plop
mars 01 21:59:47 leo.lan rpc.gssd[4111]: ERROR: gssd_refresh_krb5_machine_credential: no usable keytab entry found in keytab /etc/krb5.keytab for connection with host ns7dev3
mars 01 21:59:47 leo.lan rpc.gssd[4111]: ERROR: No credentials found for connection to server ns7dev3
mars 01 21:59:47 leo.lan rpc.gssd[4111]: WARNING: gssd_clnt_gssd_cb: failed reading request
lines 495-547/547 (END)