[Samba] NFS4 ACLs with samba 3 (or 4)

Nico Kadel-Garcia nkadel at gmail.com
Sun Mar 22 00:05:09 MDT 2015


On Sat, Mar 21, 2015 at 5:16 PM, Robert Schetterer <rs at sys4.de> wrote:
> Am 20.03.2015 um 10:45 schrieb Volker Lendecke:
>> On Thu, Mar 19, 2015 at 05:47:11PM +0100, Robert Schetterer wrote:
>>>> Well the API is propably just stuffing blobs into extended
>>>> attributes directly from userspace. That's how most of
>>>> the NFSv4 ACLs usually get done :-(.
>>>>
>>>> Of course all implementations use different blobs containing
>>>> different things to do the same thing :-).
>>>>
>>>
>>> make sure that you dont run in a open files limit with ntfs4 acl on
>>> netapp ( i think this was in the orig question ) , there may be a max of
>>> 32000 per head ( if exist ) or 64000 in summa
>>
>> Are we talking about nfsv4 or ntfs(4)? And what limit is
>> that? It can't make sense to limit the number of acls on a
>> system.
>
> sorry typo nfs4 acl4, this limits where anounced recent
> on a admin meeting using a netapp filer ( no idea what version etc ),
> this forced many problems
> in the past, so the workaround was to move back to nfs3 where acl are
> not needed

If you have an NetApp that can do NFSv4, *don't bother* putting CIFS,
and all the subtly mismatched handling and difficult impedance
matching between the systems. Seriously: install the Windows "Services
For Unix" toolkits as necessary, just use NFS on both sets of clients,
and don't expect Samba to fix the mismatches for you.

I've done mixed NFSv4 and CIFS clients based on Samba on top of a
NetApp, and it's a painful and performance bottle-necking nightmare to
maintain. Few stable Linux systems have the utilities to handle NFSv4
attributes except as a painfully, confusing, manual script managed
process. There were some GUI's a few years ago, including the ones I
actived for RHEL 6's NFS utilities: they'd been disabled from
compilation in the SRPM, probably because they weren't very good. I've
not heard of any improvements, and it's very easy to break privileges
for *both* sets of clients if you're not careful.

And frankly, from my first days of Samba work on SunOS 4.1.4,  it's
been much safer and more robust to throw out the complexities of
Windows file ownership for shared network based resources and use the
simpler owner/group/others ownership of ordinary NFSv3 and standard
file system ownership on the Linux systems.


More information about the samba mailing list