Multiprotocol File Sharing via NFSv4 and Samba

Multiprotocol File Sharing via NFSv4 and Samba

[Kraus, Sebastian]

Hi all,
are there any non-commercial solutions (apart from solutions like Dell EMC, IBM and NetApp) around that allow to simultaneously access the same file system via NFSv4 and Samba exports in a (nearly) non-conflicting manner, especially w.r.t. to NFSv4/Windows ACL incompatibilities?

Best
Sebatian

____________________
Sebastian Kraus
Team IT am Institut für Chemie
Gebäude C, Straße des 17. Juni 115, Raum C7

Technische Universität Berlin
Fakultät II
Institut für Chemie
Sekretariat C3
Straße des 17. Juni 135
10623 Berlin

Email: sebastian.kraus@tu-berlin.de

Re: [Samba] Multiprotocol File Sharing via NFSv4 and Samba

[Nico Kadel-Garcia]

On Thu, Jul 2, 2020 at 2:16 PM Kraus, Sebastian via samba
<samba@lists.samba.org> wrote:
>
> Hi all,
> are there any non-commercial solutions (apart from solutions like Dell EMC, IBM and NetApp) around that allow to simultaneously access the same file system via NFSv4 and Samba exports in a (nearly) non-conflicting manner, especially w.r.t. to NFSv4/Windows ACL incompatibilities?
>
> Best
> Sebatian

I've done it at a commercial scale with locally configured NFS on
Linux clients and Samba for CIFS access on windows clients. It's very
tricky to scale, and to maintain consistent privileges. NFSv4 map
somewhat, but not *perfectly* to CIFS credentials. And lock files
become an adventure, because clients *cannot* be entirely in sync with
a centralized server, the constant monitoring and updating to be in
tight4er and tighter sync themselves cost bandwidth and CPU. So
collaboration working with the same files can require thoughtful
programming to ensure atomic operation. I don't recommend it: I'd
generally recommend picking one protocol or the other and using it
everywhere. It's extraordinarily difficult to predict
incompatibilities someone may run into with ocmmercial software,
written to use lock files with *very* peculiar behavior. And of course
there is the filesystem namespace collission issue. In NFS, README.md"
is a different file from README.MD or readme.md, and resolving this
with CIFS clients o the same workspace can be an adventure.

There are many inexpensive office grade petabyte storage servers which
rely on Samba internally and would probably serve your needs.

Re: [Samba] Multiprotocol File Sharing via NFSv4 and Samba

[Björn JACKE]

On 2020-07-02 at 18:04 +0000 Kraus, Sebastian via samba sent off:
> are there any non-commercial solutions (apart from solutions like Dell EMC, IBM and NetApp) around that allow to simultaneously access the same file system via NFSv4 and Samba exports in a (nearly) non-conflicting manner, especially w.r.t. to NFSv4/Windows ACL incompatibilities?

related to this topic the NFS4 ACL overview in the wiki:
https://wiki.samba.org/index.php/NFS4_ACL_overview

Björn

Re: [Samba] Multiprotocol File Sharing via NFSv4 and Samba

[Björn JACKE]

On 2020-07-02 at 18:04 +0000 Kraus, Sebastian via samba sent off:
> are there any non-commercial solutions (apart from solutions like Dell EMC, IBM and NetApp) around that allow to simultaneously access the same file system via NFSv4 and Samba exports in a (nearly) non-conflicting manner, especially w.r.t. to NFSv4/Windows ACL incompatibilities?

related to this topic the NFS4 ACL overview in the wiki:
https://wiki.samba.org/index.php/NFS4_ACL_overview

Björn

Re: Multiprotocol File Sharing via NFSv4 and Samba

[Daniel Kobras]

Hi!

Am 02.07.20 um 20:04 schrieb Kraus, Sebastian:
> are there any non-commercial solutions (apart from solutions like Dell EMC, IBM and NetApp) around that allow to simultaneously access the same file system via NFSv4 and Samba exports in a (nearly) non-conflicting manner, especially w.r.t. to NFSv4/Windows ACL incompatibilities?

You seem to anticipate cross-platform incompatibilities, but mind that
using NFSv4+ACLs on Linux is a problem all by itself. Essentially all of
Linux userland is ignorant about NFSv4 ACLs, so even with basic tasks
one tends to risk subtle breakage. Note that it's a client-side issue
that also affects the cited commercial servers.

To illustrate the point, just try the following sequence of commands on
an arbitrary v4 mount on a Linux client:

  % touch aclfile
  % chmod 644 aclfile
  % nfs4_setfacl -a A::otheruser@example.org:RW aclfile
  % nfs4_getfacl aclfile

  # file: aclfile
  A::OWNER@:rwatTcCy
  A::otheruser@example.org:rwatcy
  A::GROUP@:rtcy
  A::EVERYONE@:rtcy

  % cp -p aclfile aclfile-copy.v4

If the NFS server and its backing filesystem natively supports NFSv4
ACLs, `cp -p` will 'just' lose the ACLs that don't correspond to mapped
mode bits. If they're mapped to Posix ACLs, it's even worse, and the cp
command that was supposed to preserve permissions, has also just granted
write access to the group:

  % nfs4_getfacl aclfile-copy.v4

  # file: aclfile-copy.v4
  A::OWNER@:rwatTcCy
  A::GROUP@:rwatcy
  A::EVERYONE@:rtcy

Kind regards,

Daniel
-- 
Daniel Kobras
Principal Architect
Puzzle ITC Deutschland
+49 7071 14316 0
www.puzzle-itc.de

-- 
Puzzle ITC Deutschland GmbH
Sitz der Gesellschaft: Jurastr. 27/1, 72072 
Tübingen

Eingetragen am Amtsgericht Stuttgart HRB 765802
Geschäftsführer: 
Lukas Kallies, Daniel Kobras, Mark Pröhl